Three Layers, One Graph -- A Reference Architecture for Processing Legal Documents on AWS

The same contract reads differently depending on what you ask of it, so a document AI system needs more than similarity search. This talk splits what we know about a document into three layers (physical structure, domain entities, workflow knowledge) and builds the graph in the middle one, resolving every defined term, citation and party before anything is indexed. It then shows the reference architecture on AWS: Textract, the GraphRAG Toolkit on Neptune and OpenSearch, and agents on Bedrock AgentCore.

Transcript

9. Document perceive Physical structure pages, blocks, tables, reading order ground Domain entities parties, roles, dates, clauses, references infer Workflow knowledge review checklist, fraud indicators Answer collapsed: it fails, but not in a place
12. Loan agreement External legal source art. 1341 c.c. URN:NIR Art. 1 Definitions “Interest Rate” means… outward Annex B formula, parameters inward Amendment No. 1 new Interest Rate Clause 4.2 “Interest Rate” · art. 1341 · Annex B Guarantee “the Bank” across the case
15. Loan agreement “the Bank” Guarantee “Lender” same party Banca Esempio S.p.A. one entity node Query the case as a whole Pledge deed “Banca Esempio S.p.A.”
17. AWS Cloud Indexing Resolve in, out, across S3 Textract Normalize GraphRAG Toolkit input or Docling, Mistral IR + stable IDs extract + build S3 lexical canonical layer artifacts User S3 skills Bedrock OpenSearch Neptune models embeddings one graph Gateway Search Lookup MCP tools Toolkit engine BYOKG-RAG Querying Conversational agent Task agent harness + skills subagent
20. GraphRAG Toolkit Resolve Lambda “the Bank” Party Banca Esempio chunk one party stable ID “Lender” Party fact “Interest Rate” Definitions DefinedTerm art. 1, annex A “art. 1341 c.c.” Civil Code StatutoryReference URN:NIR