Intermediate
English
Abstract
The same contract reads differently depending on what you ask of it: a loan agreement reads one way when you are checking whether an early-repayment clause holds, another when you are estimating tax exposure, another again when you are looking for anomalies in a due diligence. The structure worth extracting depends on the document and on the question. For some years now I have thought about documents through a three-layer model, and at Lidia we built the architecture in this talk on top of it.
The first layer is the document's physical structure: pages, blocks, tables, section headers, reading order, what a layout analysis engine gives back. The second is the layer of domain entities and their relations: parties, roles, dates, clauses, references. The third is the knowledge that serves one workflow and no other, the checklist of a contract review or the indicators of a fraud check. Keeping them apart has a practical consequence: the first is recomputed when the extraction engine changes, the third when the use case changes, and the second has to survive both.
Nothing about the model is specific to law; it works the same on an invoice or a novel. I use legal text because it is the domain where a badly resolved reference is not a slightly less relevant search result: it is a wrong opinion with somebody's signature on it.
The hard work sits in the second layer, in three resolution passes over references, all of them before anything is indexed. Inward: "Interest Rate" with capitals means whatever the Definitions article says it means, and binding it to the general economic sense produces a grounding error that no downstream check catches, because the answer stays coherent and well written. Outward: "pursuant to art. 1341 of the Italian Civil Code" or "in accordance with Regulation (EU) 2016/679" have to be carried to a canonical identifier (URN:NIR for Italian law, ELI for Union law), and only then does the reference become queryable: is it apt to the clause it appears in, is it still in force, has it been repealed? Across documents: the same company appears as "the Bank", as "Lender", and under its full registered name in three instruments of the same matter, and connecting those occurrences to a single node is what lets you query the matter as a whole.
On AWS: Textract in LAYOUT mode, its output normalized into an engine-agnostic intermediate representation, identifiers derived from content and structural position (so a re-extraction yields the same IDs and the graph is not rebuilt), the three resolutions run over that representation, the graph on Neptune and the embeddings on OpenSearch. Indexing and querying go through AWS Labs' GraphRAG Toolkit, which builds a lexical graph (source, chunk, topic, statement, fact, with entities attached to facts) and has a configurable extraction stage: domain entity classifications in place of generic ones, extraction prompts rewritten for contractual language, and domain labels and canonical identifiers carried into the graph.
Bedrock Knowledge Bases offers managed GraphRAG on Neptune Analytics with cross-document reasoning, and for many cases it is perfectly good. It does build the graph for you without exposing the build stage, and in a legal setting that is exactly the step to control and measure: the point where a reference is bound to the definition the document itself gives, or to a canonical statutory identifier.
Janos Tolgyesi
Senior AI Specialist @ LIDIA — AWS Community Builder
Bio
Janos has many years of experience in machine learning, generative AI, and software architecture. He has led advanced projects in Computer Vision, Big Data, Generative AI, and MLOps, both in corporate environments and within the open-source community. He has been an AWS Community Builder for five years, co-organizer of the [Gen]AI Meetup in Milan, and an active technical evangelist.
At LIDIA, Janos contributes to the development of advanced AI solutions, bringing strategic vision and strong execution capabilities to the startup’s most challenging projects.
