Connect ChatGPT to a SQL database: define the answer contract first

Connecting ChatGPT to a SQL database is the easy part.

The harder question is what a trustworthy answer must contain. Without a shared contract, one prompt returns a global total, the next inherits a tenant from chat history, and a third silently uses yesterday's definition of an active customer.

Define the answer contract before choosing prompts, tools, or dashboards.

An answer is more than a value

A useful database answer should carry enough context for a person to judge it. At minimum, define:

• identity: who requested the answer and under which role;
• scope: tenant, environment, region, product, and time window;
• meaning: the approved metric or business definition;
• freshness: source timestamp and acceptable staleness;
• limits: rows, bytes, runtime, and permitted detail level;
• evidence: source, filters, query or operation reference, and trace ID;
• uncertainty: ambiguity, truncation, missing data, and assumptions;
• next action: answer, clarify, narrow, refuse, or request approval.

This contract turns a fluent response into a reviewable data product.

Keep identity and scope outside the prompt

The model should not choose its own tenant, production environment, or database role. Bind identity and scope from authenticated application context and enforce them through database roles, row-level policies, approved views, or a trusted service layer.

Conversation text can ask for a narrower scope. It should not widen the structural one.

Start with the ChatGPT database connector architecture and make every tool call carry explicit scope.

Give business metrics a version

Questions such as “What is revenue?” or “How many active customers do we have?” often have several valid answers. The contract should point to an approved metric definition with owner and version.

If no approved definition exists, the system should ask a clarifying question instead of improvising a calculation. If two definitions are relevant, label both and explain the difference.

Schema context explains tables and columns. Metric context explains what the organization means.

Make freshness visible

A correct query against a delayed replica may still produce the wrong operational decision. Return the source timestamp, ingestion watermark, or replica lag that matters for the workflow.

Define freshness per use case. A weekly planning report may tolerate yesterday's snapshot. An incident workflow may require data from the last few minutes and should fail closed when that condition is not met.

Bound the question before SQL runs

The answer contract should constrain date range, dimensions, joins, row count, result bytes, query runtime, and concurrency. An unbounded request should become a clarification or a smaller aggregate—not an expensive best effort.

For record-level results, use progressive disclosure: summary first, a small redacted sample second, and a separately authorized expansion only when necessary. See ChatGPT database query data minimization.

Return provenance with the result

A number without provenance is difficult to challenge. Include the approved operation or view, normalized filters, metric version, data timestamp, row count, truncation state, and a trace reference.

Do not expose secrets or copy raw sensitive data into logs. The goal is to reconstruct how the answer was produced, not to create a second data leak.

The audit-ready MCP database workflow provides a deeper evidence checklist.

Treat ambiguity as a normal outcome

A trustworthy connector does not need to answer every question immediately. Define common ambiguity classes:

• missing tenant or environment;
• undefined business metric;
• unclear timezone or comparison period;
• request wider than the user's role;
• result too large for the approved workflow;
• stale schema or freshness outside the allowed window.

Map each class to a deterministic response: ask one specific question, narrow to a safe default that is explicitly labeled, refuse, or request human approval.

A concrete contract for a renewal question

A customer-success manager asks: “Which renewals need attention next month?”

The tool contract supplies the authenticated tenant and role, resolves “next month” in the user's timezone, uses the approved renewal-risk definition, restricts the source to an approved view, and returns an aggregate plus at most 20 redacted records.

The answer states the source watermark, applied filters, metric version, number of matching records, omitted sensitive fields, and whether the list was truncated. A request for case notes becomes a separate lookup with its own authorization decision.

Test the contract, not only the demo

1. Omit tenant, environment, timezone, and metric definition one at a time.
2. Request another tenant's record directly and through an aggregate.
3. Change a schema field and a business definition independently.
4. Delay the source beyond its freshness threshold.
5. Exceed row, byte, date-range, and runtime limits.
6. Verify that provenance and truncation survive every successful response.
7. Confirm that clarification and refusal are deterministic and auditable.

Where Conexor fits

Conexor provides MCP infrastructure for connecting ChatGPT and other AI clients to databases and APIs through governed tools. The answer contract defines what those tools must preserve: identity, scope, meaning, freshness, limits, and evidence.

Explore the ChatGPT database connector

Then use the negative-test scorecard to compare implementations.