Do not connect ChatGPT to the MySQL writer first

The risky part of connecting MySQL to ChatGPT is not the first successful answer.

It is proving that a new question workload can reach live data without competing with checkout, support, billing, or other production traffic.

A better first production path:

1. choose one bounded question family
2. create a dedicated read replica or isolated reporting path
3. use a purpose-built MySQL identity
4. expose typed business operations, not arbitrary SQL
5. measure replica freshness explicitly
6. run answer-parity and negative contract tests
7. set connection, query, row, byte, and lag budgets
8. shadow representative questions
9. enable a small cohort with a kill switch

The result contract should include the source, filters, observation time, freshness state, row count, truncation, and trace ID.

If the replica is outside the workflow's freshness budget, return a structured stale-data result. Do not quietly turn old data into a confident answer.

A read replica is not the whole security model. It is a separate failure domain that makes load testing, canarying, and rollback much easier.

Full tutorial: How to connect MySQL to ChatGPT with a read-replica cutover