Challenge
The navigation and theme tools tell the agent what the documents say. Judgment tells it what actually worked - by federating: grounding in the document graph, then reading the repair history from live BigQuery.
This is where neocarta earns its place. The agent does not run a hand-written query - it retrieves the warehouse schema from the connections graph and writes the SQL itself. That is Text2SQL grounded by the foreign keys, so the joins are correct.
How the agent judges
Open skill/SKILL.md and find the Judgment section. It is a policy, not a script. For any warehouse fact, the agent:
-
Retrieves schema from the connections MCP server with get_full_metadata_schema - every table with its columns and foreign-key references, the join paths from Module 2.
-
Grounds in Neo4j - which documents cover the code, which parts they name, with grounding section URIs.
-
Writes and runs the SQL with run_sql.py, joining along those foreign keys.
-
Ranks the result - evidence beats guidance, zero comebacks wins.
Two judgment questions close the case for Dani’s misfire:
-
What fixed P0301 on vehicles like CM-FAL-2020-0451? - candidate parts from the documents, ranked by real outcomes on similar vehicles.
-
What open recall has CM-FAL-2020-0451 never had? - recalls in scope for the model whose remedy part is current and was never applied to this vehicle.
Why this needs the connections graph
The fix question crosses the boundary: it starts in document trees (which documents cover this code, which parts do they name) and ends in warehouse history (which work orders replaced that part, did the vehicle come back) - two different stores. The bridge is the shared key: the part number the document names is the same string the BigQuery rows use.
And the warehouse join - work orders to vehicles to parts - is four tables. Text2SQL gets queries on four or more tables wrong roughly 79% of the time when it guesses the joins (Falcon, 2025). The agent does not guess: it reads the foreign-key references from the connections MCP and writes the join correctly. No vector index can return this answer; federation on the key, grounded by the connections shape, is why it works.
Run it on Dani’s bay
Ask your agent to answer both questions, and tell it to use the connections graph for schema and run_sql.py to run the SQL:
Watch it call the connections tools, write the SQL from the foreign keys, and run it. Read the evidence - the top fix and the one open recall - then answer the questions below. The recall result means the misfire in the bay and an open safety recall are the same story, found by crossing from the document graph to the live warehouse without either store moving into the other.
Want to see it as code?
Deterministic Python versions are in solutions/scripts/what_fixed_this.py and solutions/scripts/recall_exposure.py. Run them to check the agent’s answer, or read them to follow the federation step by step.
The Right Fix
According to what_fixed_this.py, which part fixed code P0301 on vehicles like Dani’s with zero comebacks?
-
❏ IC-2042-A, the original ignition coil
-
✓ IC-2042-B, the revised ignition coil
-
❏ SP-1108, the spark plug set
-
❏ CAT-5500, the catalytic converter
Hint
Sort order matters: the spec orders by comebacks ascending, so the best-performing part is the first row of the tool’s output.
Solution
The correct answer is IC-2042-B, the revised ignition coil.
It was used on five work orders for Falcon 2.0T vehicles diagnosed with P0301, and none of those vehicles came back.
The original coil IC-2042-A was used four times - and all four vehicles returned with the same code, which is exactly what bulletin TSB-21-114 warns about.
Open Recall Exposure
Which vehicle is in scope for recall RC-2021-04 but never received the remedy part?
-
❏ CM-FAL-2019-0102
-
❏ CM-FAL-2020-0317
-
✓ CM-FAL-2020-0451
-
❏ CM-FAL-2021-0529
Hint
Run recall_exposure.py for each candidate VIN - only one returns a recall.
You have seen that VIN before.
Solution
The correct answer is CM-FAL-2020-0451 - the 2020 Falcon in Dani’s bay.
Every other in-scope Falcon already received the revised coil during a repair, so recall_exposure.py returns nothing for them.
The car with the unexplained misfire is also the car with the open recall - a connection that existed in the data all along, but only federating the document graph with the live warehouse could surface.
Summary
The agent judged by federating, live:
-
Schema from the connections MCP - the foreign-key join paths, so the Text2SQL is correct, not guessed
-
What fixed this - guidance ranked by real outcomes; the revised coil wins with five repairs and zero comebacks
-
Recall exposure - the car in the bay is the one vehicle with open recall exposure
-
The cross-boundary answer works because the document graph and the warehouse meet on the shared key
In the final challenge, your agent puts judgment and action together on a live work order.