ChatGPT enterprise database connection: define an answer freshness contract

An enterprise ChatGPT answer can be correct and already too old.

The query may have run seconds ago while the warehouse snapshot is six hours old. A cache may contain yesterday's schema. A late-arriving event may change the total after the answer is delivered. If the response shows only a polished number, the reviewer cannot tell which kind of freshness they received.

A production ChatGPT enterprise database connection therefore needs an answer freshness contract.

Freshness is more than query time

Teams often add “generated at 10:04” to a response and consider the problem solved. That timestamp says when the answer was assembled. It does not say when the source last changed, which snapshot was queried, when upstream ingestion completed, or whether cached metadata influenced the operation.

Treat freshness as a chain with at least five clocks:

• event time: when the business event actually happened;
• ingestion time: when the event reached the analytical source;
• source snapshot time: the database state visible to the query;
• query time: when the approved operation executed;
• answer time: when the AI response was produced.

For operational databases, event and ingestion time may be close. For replicated systems and warehouses, the gap can be material.

Define freshness by workflow

There is no universal acceptable age. A monthly board metric and an incident triage query have different requirements. Define the contract for each approved workflow rather than setting one global number.

A useful contract states the source, metric definition, maximum source age, allowed cache age, timezone, late-arrival policy, and response when the threshold is exceeded. The safe response may be to refuse, return a clearly marked stale result, or ask the user to wait for a refresh.

Identity and execution should also remain separate. See discovery and execution credentials for enterprise database connections.

Return evidence with every answer

The result envelope should make review possible without exposing unnecessary raw data. Include:

• source and approved operation or view;
• tenant, environment, and timezone scope;
• source snapshot or replication watermark;
• query start and completion time;
• metric and schema version;
• cache age for schema, metadata, and result data;
• filters, row count, truncation, and late-arrival cutoff;
• trace ID for independent reconstruction.

The model should not invent this evidence. The connector or MCP server must attach it from trusted runtime state.

Separate three caches

“The cache” is too vague for production review. Schema metadata, authorization decisions, and result data have different invalidation rules.

1. Schema cache: invalidate on schema version or migration changes.
2. Policy cache: bind to principal, tenant, role, policy version, and expiry.
3. Result cache: bind to normalized inputs, source watermark, and workflow-specific TTL.

Never let a result cached for one identity or tenant become reusable by another because the natural-language question looked identical.

Concrete example: open incident count

An operations manager asks, “How many high-priority incidents are open right now?”

The connector queries an approved view at 10:04 UTC. The replica watermark is 10:01, the event stream is complete through 09:59, and the workflow permits a maximum source age of five minutes. The response returns 17 incidents and states that events after 09:59 may not yet be included.

If the watermark were 09:42, the same query should not silently return a definitive “17”. The contract could return “17 as of 09:42; freshness threshold exceeded” and require a refresh or explicit acceptance of stale data.

Test the failure modes

1. Pause ingestion while the database remains reachable.
2. Change a view or metric definition without refreshing metadata.
3. Replay the same question after the result TTL expires.
4. Send a late-arriving record across the reporting cutoff.
5. Switch tenant, role, or environment while keeping the question identical.
6. Force clock skew and timezone ambiguity.
7. Verify that traces reproduce the displayed timestamps and scope.

A connector fails the test if it produces confident prose while hiding that the source, schema, or policy context is stale.

Where Conexor fits

Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. A freshness contract makes source state and answer evidence explicit at that boundary.

Explore the ChatGPT database connector

For the complementary runtime evidence, use the audit-ready MCP database workflow and the database result provenance checklist.