Building a Real Estate Due Diligence Agent with a Graph Database: 81% Hidden Risk Detection Rate

If you've seen the brochures for new developments in Bangalore, you're familiar with the pitch: renderings, clubhouse, "RERA certified," launch offers. What you can't see is the history of the people behind it. Developers typically register a new company for each project—this is legal and common, but it also means a brand-new, clean-record company may be run by the same directors whose previous company went bankrupt, leaving homebuyers with a half-built tower. The plot's previous owner may be mired in title litigation, and the contractor may already be two years behind schedule on three other sites.

This information isn't hidden—it exists in RERA filings, corporate records, court records, and land records. It's just never been connected and presented to the homebuyer. An open-source project called Khoj attempts to solve this: rather than relying on any single record, it builds a graph of "who is connected to whom" and uses graph algorithms to compute a risk score along relationship paths. On 200 test projects that looked clean on the surface but harbored hidden risks, a method that only examines a project's own records achieved a detection rate of 0%, while Khoj's graph-based method achieved 81% with zero false positives.

Why Risk Hides in Relationships

The Khoj author sums up the core insight of due diligence in one sentence: the answer to "Is this project safe?" isn't in any single record—it's in the relationships between records. A newly launched project may have a clean RERA filing, A-khata land, and zero complaints, but its company may share two directors with a developer currently in bankruptcy proceedings, leaving behind two stalled projects. Traditionally, a homebuyer would have to manually cross-reference multiple databases to uncover this connection, whereas a graph database is purpose-built for exactly this kind of multi-hop relationship.

The knowledge graph is modeled after what a cautious real estate lawyer would pay attention to: developer brands CONTROL companies, individuals are DIRECTOR_OF companies; companies DEVELOPS projects, projects are BUILT_ON plots, plots were PREVIOUSLY_OWNED_BY someone; contractors BUILDS projects, approvals hang off projects; complaints are AGAINST projects, and court cases INVOLVE land, companies, individuals, or contractors. Any entity that on its own constitutes a warning signal—a stalled project, a bankrupt company, pending litigation, a B-khata plot—is tagged with :RedFlag, along with a severity level and reason.

The demo data is synthetic but realistic: 91 projects, 46 companies, 100 individuals, distributed across real Bangalore localities, generated with a fixed seed, with all names fictional. The typical story the author planted is Skyvista Altura: a brand-new launch on Sarjapur Road with full RERA compliance, A-khata land, and zero complaints—it looks perfect, until you discover that its company shares two directors with Northstar Habitats, which is in bankruptcy proceedings and has left behind two stalled projects.

RERA, A-khata, B-khata: RERA is the abbreviation for India's Real Estate (Regulation and Development) Act (2016), which requires each state to establish a real estate regulatory authority. Developers must register projects and disclose information such as promoters, land title, approvals, and construction progress, which homebuyers can use to check project compliance. Khata is a municipal tax register document in Bangalore and elsewhere, essentially a property's "tax household registration." A-khata refers to fully compliant properties with paid land taxes and clear title, which can be freely transacted and used for loans; B-khata typically refers to properties that are not fully compliant, with defects in title or approvals, limiting transactions and loans—and therefore constituting a warning signal in due diligence. These records are public but scattered across different systems, which is exactly the kind of data source a knowledge graph needs to connect.

Turning Paths into Explainable Scores

Khoj's risk score is designed to be "explainable by construction"—behind every point is a path. For each project, a Cypher query finds all paths up to four hops that lead to a red flag, filtering out paths that pass through other projects and limiting land-ownership edges to at most one use. Each path contributes the severity of its flag, decaying by distance and per-edge relationship strength, ultimately aggregated into a Katz centrality-like score:

K(p) = Σ over paths P: severity(f) · 0.6^(hops−1) · Π edge weights

score = 100 · (1 − e^(−K))

For Skyvista Altura, 10 paths sum to K=1.87, giving a score of 84.6/100. This design deliberately sums all paths: a company sharing two directors with a failed developer should be more dangerous than one sharing only one.

Lesson One: Calibrate Against the Whole Graph, Not the Demo Sample

The first version correctly identified Skyvista Altura but also scored the median project at 94. The reason: contractors and land aggregators are hub nodes, and paths run from a project to a contractor, then to another project, then to that project's 30 complaints—everything looks dangerous. Two structural rules fixed this: paths cannot pass through another project (a stalled project is itself a red flag, and its complaints shouldn't be counted against its neighbors); and a path may use at most one land-ownership edge (preventing land aggregators from connecting unrelated projects). The median dropped to 28, clean projects scored 0, and the planted story still stood out.

Katz centrality is a path-based centrality measure that considers not only the shortest path between nodes but sums over paths of all lengths with length-based decay, thereby measuring a node's influence across the entire network. The formula is typically (C_{Katz}(v)=\sum_{k=1}^{\infty}\alpha^k\sum_{u}A^k_{vu}), where (\alpha) is the decay factor and (A) is the adjacency matrix. Khoj borrows this idea, summing all paths from a project to red flags with exponential decay by hop count, so that the risk score reflects both direct and indirect connections, and every path is traceable and explainable.

Graph Algorithms as Agent Tools

The two questions a homebuyer should ask—"Who is actually behind this brand?" and "Are there serial operators here?"—map directly to FalkorDB's built-in algorithms. Weakly connected components run on the director-company graph, and companies in the same component form a hidden group, regardless of the brand they operate under. Betweenness centrality identifies directors who bridge different companies: in the demo, one person sits on six boards across four brands, two of which failed, ranking him first among all directors in the market.

Lesson Two: Algorithms Have Opinions About Direction

FalkorDB's betweenness centrality respects edge direction. The author's edges all point from Person → Company, so no shortest path "passes through" a person, and all scores return zero. This was fixed by adding a reverse HAS_DIRECTOR edge for each director relationship; the issue and a minimal reproduction are documented in the repository.

Weakly Connected Component refers to a set of nodes that remain mutually connected in a directed graph when edge direction is ignored. On the director-company graph, companies within the same weakly connected component form an affiliated group through shared directors (regardless of direction), which can be used to discover hidden groups that appear to be different brands but are actually controlled by the same people. Betweenness centrality measures how often a node acts as a "bridge" on the shortest paths between other nodes; the higher the score, the better the node connects different groups. In a director network, individuals with high betweenness centrality are often key connectors across multiple companies, potentially revealing serial operators. Graph databases like FalkorDB have these algorithms built in and can be called directly as Agent tools.

The Agent Doesn't Write Cypher

Letting the model write queries directly is tempting, but the author didn't do that. Instead, the Agent gets eight hand-written, parameterized tools exposed via MCP; the model is only responsible for selecting tools and filling in parameters, and all queries execute read-only. Each result is also annotated with an answer type: ANSWERED_WITH_PATH (there is a relationship in the graph—here is the path), ANSWERED_FROM_MEMORY (discovered earlier, with a date), NOT_IN_GRAPH (no known connection, but this does not mean safe), UNKNOWN_ENTITY (the name couldn't be resolved, so no query is executed).

"The Agent proposes, the code adjudicates." Before a finding is saved, a deterministic verifier recomputes scores from the graph, checks conclusions against fixed rules, and rejects any evidence that mentions an entity the tools never returned. Numbers the model produces itself are always replaced by computed values.

This design separates the LLM's flexibility from the determinism of graph queries, preventing model hallucinations from contaminating due diligence conclusions.

MCP (Model Context Protocol) is an open protocol for standardizing how large language models connect to external tools and data sources. It allows models to discover and invoke tools through a unified interface without hardcoding query logic into prompts. In Khoj, MCP exposes eight hand-written, parameterized graph query tools to the Agent; the model only selects tools and fills in parameters, and all queries execute read-only. This architecture separates the LLM's semantic understanding from the determinism of graph queries, reducing the risk of the model generating erroneous queries while also making tools easier to audit and control.

Memory, and Two Agents Coordinating Through the Graph

A due diligence assistant that forgets your budget every time isn't very useful. FalkorDB can hold multiple graphs in a single instance, so each homebuyer gets an independent memory graph, with no leakage between them. The memory graph stores preferences and their history (changing a budget creates a new node that SUPERSEDES the old one), standing rules (such as "always check land title"), sessions, shortlists, and case files.

The system has two Agents: the Concierge talks to you and owns memory, while the Investigator owns the market graph. They hand off through the graph itself: the Concierge opens a Case node, the Investigator writes Finding nodes into it, and the Concierge reads them back. The author's favorite moment: two clean projects on the shortlist, then market events are added to the graph (a contractor's bankruptcy filing, a new title lawsuit), and when you return, Khoj greets you before you say a word: "Whispering Woods went from 0 to 52," with the exact new paths.

Proving the Graph Is Actually Doing the Work

"It breaks without the database" is easy to claim, so the author measured it. The benchmark injects 200 new projects into a copy of the graph, each clean on the surface; half hide one of four risk patterns, and half are clean controls with traps (such as sharing a locality and bank with a stalled project). The most surprising line in the results: the ablation without the two structural rules found almost all the risks but mislabeled 93% of the clean projects. The graph matters, but how you walk it matters just as much. The author also recomputed every score using pure-Python path enumeration, with zero discrepancies against the FalkorDB results.

Lesson Three: Let the Benchmark Embarrass You

A title lawsuit involving only a plot's previous owner scored slightly below the threshold, because the model decayed it like any other hop. But in property law this is wrong: you inherit the seller's title. So hops along the title chain now don't decay. This change was made after seeing the benchmark results, and it's honestly documented in the report.

Next Steps and Takeaways

The schema maps directly to real public data sources: K-RERA, MCA corporate filings, eCourts, and Bhoomi land records. With real outcome data, hand-set severity levels could be fitted rather than chosen. The author's core conclusion: the graph isn't just storage for the Agent—it makes the Agent's answers verifiable. When Khoj says "avoid," it shows the path, and you can verify it yourself.

Khoj is open source, with a stack of FalkorDB, MCP, and Streamlit. For those interested in deploying AI Agents, this project's value isn't in real estate itself but in demonstrating a pattern: constrain the LLM to a fixed toolset, use graph algorithms for deterministic scoring, use a verifier to catch hallucinations, and use path display to achieve explainability. This combination can be transferred to supply chain due diligence, investment screening, compliance review—any scenario where "risk hides in relationships."