aditya gupta Jaipur, Rajasthan, India 3H AGO

I built an evidence-driven AI workflow for extracting trustworthy investment intelligence from messy real-estate documents. The problem was not simply how to ask an LLM questions about PDFs. Real-estate investment information can be spread across reports, underwriting documents, valuation materials, rent schedules, tables, and multiple versions of the same information. A metric such as IRR can also appear several times with different scenarios, dates, or meanings. Instead of building another generic “chat with your PDFs” agent, I designed the workflow around a simple principle: Don’t make the agent smarter. Make the workflow harder to fool. The workflow follows: Look → Extract → Validate → Resolve Step-by-step: 1. I start with a business question, such as finding a particular investment metric for a specific real-estate asset. The workflow determines what the metric actually means instead of immediately searching for matching words. 2. I normalize the asset or entity using known names, aliases, and identifiers. This prevents an ambiguous asset name from causing the retrieval system to search the entire document collection indiscriminately. 3. I create a metric-specific retrieval plan. Each important metric has a governed definition describing what counts as valid evidence, where the value is normally found, which terminology is relevant, and which contexts should be avoided. The agent uses this information to create a focused retrieval plan. 4. I find the right document before finding the right chunk. Rather than immediately performing broad semantic search across every document, the workflow first narrows down the most relevant candidate documents. Once the appropriate document is identified, retrieval is performed within that document where possible. This document-first approach reduces irrelevant matches and makes the evidence easier to trace. 5. I retrieve supporting evidence from the selected documents. When ordinary text retrieval is insufficient, the workflow can escalate to structured content such as tables and page-level information, because important real-estate metrics frequently appear in financial tables rather than normal paragraphs. 6. I extract a small, structured result containing the metric, value, unit or context, source document, evidence location, and supporting citation information. The goal is not to generate a long answer but to produce a useful business value that can be traced back to its source. 7. I validate the extraction against the metric definition, expected format, units, scenario, chronology, and available evidence. Retrieval success does not automatically mean extraction correctness. 8. I resolve competing values using explicit rules based on factors such as source precedence, chronology, scenario classification, and metric meaning. If multiple plausible values are found, the system does not simply pick the first answer or average the results. If the conflict cannot be safely resolved, the workflow preserves the ambiguity rather than hiding it. 9. I produce a structured, business-ready result containing the selected metric together with the evidence and context needed to understand where it came from and why it was selected. The result can then be consumed by downstream reporting, analytics, or decision-support workflows. The most important architectural decision was separating retrieval, extraction, validation, and resolution rather than asking one LLM call to perform all four tasks. This turns an otherwise unreliable document Q&A problem into a governed workflow where every important answer has a path back to evidence. The same pattern can be recreated for other domains where information is fragmented across documents and correctness matters, including financial research, legal documents, insurance, compliance, due diligence, and enterprise knowledge systems.