The missing table: why SQL access still needs a map

An AI can run valid SQL and still miss the table that answers your question. Database access exposes facts. It does not automatically explain which facts belong together or what your business means by “available.”

Ben Squire’s talk, “Missed Connections: same agent, same data, three levels of context”, published by Datastrato on October 4, is a useful starting point. In the opening section, around 3:00–4:06, he introduces different levels of context and a starting point with BigQuery MCP access alone. We reviewed the description and opening transcript excerpt, not the full talk. His graph and ontology tooling is separate from Bufflehead; this post does not reproduce his demo or imply his endorsement.

A fictional order with a hidden alternative

Ask: “Which warehouse can fulfil order 101 under our two-day transfer rule?” The order needs three blue mugs and is assigned to warehouse 1. Its assigned warehouse has no stock. Warehouse 2 has five mugs, warehouse 3 has ten, warehouse 4 has eight, and warehouse 5 has two.

A query that checks only the assigned warehouse reports no stock. That observation is correct, but it does not establish that the order has no eligible fulfilment option. A query that searches every warehouse finds stock at warehouses 2, 3 and 4, but still cannot establish eligibility.

The missing table is fulfilment_routes. The route from warehouse 1 to warehouse 2 is enabled and takes one day. The route to warehouse 3 is disabled. The route to warehouse 4 takes four days. Warehouse 5 has an enabled one-day route but insufficient stock. Under the stated rule, only warehouse 2 qualifies.

Supply the relationship and the rule

Here is the context to give the AI alongside the schema:

Join orders to stock by SKU. The assigned warehouse is orders.warehouse_id. For an alternate warehouse, join fulfilment_routes.source_warehouse to the assigned warehouse and fulfilment_routes.alternate_warehouse to stock.warehouse_id. A single warehouse must have enough stock for the entire order. An alternate qualifies only if its route is enabled and transfer_days is at most two. Return every eligible warehouse; do not reserve inventory or promise a shipping date.

This is business context supplied by the operator. A foreign key or a column name alone would not establish the two-day cutoff, whether stock can be split, or whether disabled routes count.

Inspect the SQL and check the answer

SELECT o.id AS order_id, s.warehouse_id,
       CASE WHEN s.warehouse_id = o.warehouse_id
            THEN 0 ELSE r.transfer_days END AS transfer_days
FROM fulfilment_demo.orders o
JOIN fulfilment_demo.stock s ON s.sku = o.sku
LEFT JOIN fulfilment_demo.fulfilment_routes r
  ON r.source_warehouse = o.warehouse_id
 AND r.alternate_warehouse = s.warehouse_id
WHERE o.id = 101
  AND s.available >= o.quantity
  AND (s.warehouse_id = o.warehouse_id
       OR (r.enabled IS TRUE AND r.transfer_days <= 2))
ORDER BY transfer_days, s.warehouse_id;

On our disposable PostgreSQL 14 fixture, this returns 101 | 2 | 1: order 101, warehouse 2, one transfer day. We also checked seven changes independently: disabling that route, making it too slow, reducing stock below three, removing the route, changing the stocked SKU, adding sufficient assigned-warehouse stock, and setting the alternate route to exactly two days. All matched their expected results. Each mutation was rolled back.

The fixture, query and verification script are available to reproduce these checks in a disposable database. They create fictional data; do not run the setup against a production database.

A comparison you can run with your AI

Start two fresh conversations using the same model, question, database snapshot and read-only access. In the first, provide the schema and question. In the second, add the relationship map and rule above. Keep the tool results, generated SQL and final answers from both. Compare each answer with the known fixture result.

We have tested the SQL fixture, not this two-conversation AI experiment. Schema-only access might already produce the right answer. If it does, record that. If it misses the route table or invents a rule, the SQL and tool trace will show where. A single comparison is an example, not evidence of a general accuracy improvement.

Where Bufflehead fits

Bufflehead supplies read-only database queries to your AI through MCP. Use a scoped database role and review the queries it runs. The fixture setup, relationship map and fulfilment policy are external inputs; Bufflehead does not build an ontology, prepare your dataset or reserve stock.

The query establishes eligibility against a snapshot. Real fulfilment also depends on current inventory, reservations and your operational process. Make the assumptions explicit, then check whether the answer follows them.

Try Bufflehead with a small, known-answer dataset before connecting a broader database.