The Estate Questions

Warm-up: Dani’s car takes two shapes

The navigation and theme tools tell the agent what the documents say. The connections shape and a live warehouse query tell it what actually worked - the agent grounds the candidates in the documents, then reads the repair history from the warehouse.

The agent does not run a hand-written query. It retrieves the warehouse schema from the connections MCP (get_full_metadata_schema - every table with its foreign-key references, the join paths from Module 2), grounds the code in Neo4j, then writes and runs the SQL with run_sql.py, joining along those foreign keys.

For VIN FAL20T20220002 with code P0301: what fixed this on similar
vehicles?

Watch it call the connections tools, write the SQL from the foreign keys, and run it. The candidate parts come from the bulletin sections that name the code; the warehouse says which of them actually held up.

The estate: proving a negative

That was one car. The estate questions ask about the whole library at once - and the sharpest is the one a similarity tool can never answer. Documentation gaps:

Are there mismatches between our documented procedures
and the actual problems in the field? What documentation is missing, and what
documentation isn't used?

A similarity tool cannot answer this honestly. Asked what is undocumented, it returns the nearest-looking sections and concludes the codes are "documented, just buried" - a confident, wrong claim, because similarity always returns something and can never prove absence. The tree shape enumerates: it walks every document and reports the codes with zero hits.

UNWIND ['P0335', 'P0340'] AS code
OPTIONAL MATCH (s:Section)
  WHERE toLower(s.content) CONTAINS toLower(code)
RETURN code, count(s) AS library_hits

The estate: coverage, not sampling

The other estate question - Morgan wants the common patterns across the whole library:

What are the common patterns across our bulletins and recalls? How
many of our cars does each affect?

This is a coverage question, and it is where similarity retrieval breaks. Ask a top-k retriever for "patterns across all our notices" and it hands back the nearest handful - it samples, and it cannot tell you what it skipped. That is not a vendor flaw; it is what similarity retrieval is, and it is the engine under every lakehouse AI-search feature.

To feel the difference, run a plain keyword search for a broad theme first - your search.py over content_search returns the top matching sections, not the whole set. Then run themes.py: it clusters all 112 bulletins and recalls into the dozen-or-so recurring failure modes they actually represent. The shape covers the structure; the search samples it. Only then does the warehouse count make sense - the agent reads the warehouse on each pattern’s parts and codes to size the fleet exposure.

Connections at scale

The third Module 1 question - "how do these records relate?" - is the connections shape at scale. On AutoFix’s six-table warehouse, Text2SQL handles the joins fine; the failure only appears on a real warehouse with hundreds of look-alike, very wide tables, where the schema does not fit in a prompt and the model brute-forces metadata, picks the wrong table, and loops.

On independent enterprise benchmarks, models hit a *78.57% error rate on queries touching four or more tables*^[1]. The connections shape retrieves the right table and the join paths by meaning before generating SQL, so the agent never scans the haystack. You built that shape in Module 2; at production scale, it is what keeps Text2SQL reliable and cheap.