Picture a policy table with a merged header “Enterprise plans” above two columns, “Standard” and “Premium.” The row below says 50 and 100 requests per day. A text extractor emits “Enterprise plans Standard Premium 50 100” as one line. Retrieval finds the correct document, but the model has to guess which number belongs to which column. A citation to the table page does not prove the cell relationship survived.

Tables carry meaning in coordinates and hierarchy. Amazon Textract's table documentation represents cells, merged cells, column headers and row/column positions as separate structures. A RAG ingestion pipeline that flattens them to reading-order text has thrown away relationships the answer needs.

I would inspect the source page beside the extracted cell graph and the exact chunk sent to the model. For the target value, can we trace row label, column label, merged parent header, footnote and source page? Check blank cells too. Some tables use blank cells to mean “same as above,” while others mean “not applicable.” A parser must not invent either meaning without the table's conventions.

Represent each meaningful cell as a small record such as product, plan, limit, unit, effective date and source coordinates, preserving the table and header IDs. For open-ended search, index a readable rendering of those records with the surrounding policy text. For an exact plan-limit answer, retrieve the relevant cell and its headers, not a loose paragraph of adjacent values. If extraction confidence is low or a spanning header cannot be resolved, ask for review or say the table could not be read reliably.

Test with tables where a merged header spans two plans, footnotes change one column, and a plan name repeats in a different section. Compare the final answer against cell-level ground truth, not document-level recall. The core failure is structural: the system retrieved the right page while losing the join between a value and its labels.