Why would the AI get a wrong number if it's querying the real database?

Live access fixes invented tables. It doesn't fix wrong filters, wrong status values, timezone mistakes, or pointing at staging while you think you're on prod. The SQL can be valid and the business answer still wrong.

How many checks do I need before trusting the connector?

Three is enough for a smoke test: a count you know, a filtered count you know, and a join or relationship you know. If those pass, expand. If one fails, fix connection or prompts before anyone else uses the endpoint.

Should I verify on staging or production?

Staging (or a branch/replica) first. Prove the workflow where a wrong query is cheap. Move to production reads only when you need current numbers staging can't provide.

What if the AI shows SQL that looks right but the number is wrong?

Run the same SQL in your normal client, or compare to a dashboard you trust. Check Synra Usage for which connection and tool fired. Often it's the wrong database, an outdated staging refresh, or a status string the model guessed.

Does Synra guarantee correct metrics?

No. Synra runs the SQL read-only and logs the call. Definitions of MRR, active user, or churn are still yours. Verification is how you catch drift between the model and your business language.

Verify AI Database Answers | Known-Answer Checks

Live database access fixes a lot of invented tables. It does not make the first number in the chat true.

The model can write valid SQL with the wrong filter, the wrong status string, or the wrong connection — staging from last Tuesday while you assume production. Confidence isn’t a checksum.

Before you share an endpoint or put a chat number in a deck, run known-answer checks. Setup guides mention this in one line; here’s the habit.

Around it: staging first, read-only, table allowlists, usage logs.

What you’re actually checking

Not whether the model is clever. Three boring things:

Right database — the connection you think is answering is answering
Right catalog — tables and columns match what you expect
Right reading of the data — filters and joins match how you define the metric

(1) or (2) fail → fix credentials or environment. (3) fails → fix the question, add a view, or keep that metric in BI.

Pick answers you already know

Write them down before you open Cursor or Claude. Examples:

| Check | You already know | Ask the AI | |--------|------------------|------------| | Count | Staging has 1,204 rows in orders | “How many rows in orders?” | | Filter | 86 orders with status = 'paid' last 7 days (you ran SQL) | “How many paid orders in the last 7 days?” | | Join / shape | Every order_items row has an orders parent — 0 orphans | “Are there order_items with no matching order?” | | Negative | Table users is not on the allowlist | “Describe the users table” → should fail or be unavailable |

Use your real numbers. The table is a template.

Run the three smoke questions

In the AI client, with the connector enabled:

1. Bare count
“How many rows are in orders?”
Match your note. Off by a lot → wrong DB, wrong schema, or stale staging. Off by a few → maybe someone inserted during the test; re-check in psql.

2. Filtered count
“How many rows in orders where status = 'paid' and created_at is in the last 7 days?”
Use the status values your app actually writes (paid vs Paid vs complete). Models guess enums.

3. Relationship
“How many order_items rows have no matching row in orders?”
You expect zero (or whatever your known orphan count is). Catches bad joins and wrong assumptions about FKs.

Optional fourth: ask for a write you never want (UPDATE … WHERE false). Should fail. That’s the read-only check, not a metrics check.

When a check fails

Wrong count, SQL looks fine. Open Synra Usage — which credential name fired? People reuse a prod-shaped name on a staging URI (or the reverse).

Filter count wrong. Ask the model to show distinct status values. Compare to your app. Add the real enum to the question, or create a SQL view that encodes “paid” the way finance means it.

Describe/list shows tables you blocked. Allowlist didn’t save, or the client is on another endpoint. Fix table access; don’t open every table.

Numbers match staging, you’re presenting them as live. Label the chat or switch connections. Staging-first is a feature until you forget which URL you’re on.

After the smoke test

Save the three questions in a team doc: “run these when you add a connection.”
Re-run after you rotate credentials, refresh staging, or change the allowlist.
For board metrics you already fight about in Looker — keep using Looker. Chat is for ad-hoc exploration; when not to connect still applies.

A five-minute checklist

Staging (or replica) connection, SELECT-only user, tables restricted
Write three known answers on paper
Ask them in Cursor / Claude / ChatGPT
Confirm Usage shows the right credential
Confirm a deliberate write fails
Only then invite someone else

Skip step 2 and you’re guessing.

Live SQL beats pasted CSVs. Known answers beat trusting the first reply.

Staging DB at mcpserver.design (7-day Solo trial) — three checks, then decide if the numbers are worth sharing.

Related reading:

What Your AI Query Audit Log Is For — match chat time to Usage
Staging First — where to verify first
Why Read-Only AI Database Access Matters — write rejection test
How to Create a SELECT-Only Postgres User for AI — grants before the chat
Don't Give Your AI Access to Every Table — shrink what it can see
Why AI Hallucinates Your Database Schema — invented catalog vs wrong metrics