AI review for data-changing queries

Ask for a plain-language read on a query's side effects before it runs in a protected place.

In a protected context, require a plain-language review of a query's side effects before it runs. Turn it on for a client, project, environment, server, or database, and every data-changing batch on anything beneath it has to be reviewed and confirmed.

Deterministic first, narrative second

The review is two layers, in that order, and the order is the point:

1. The validator runs. A parser-backed pass over the batch produces real findings with severities - unbounded UPDATE/DELETE, unknown objects, the shapes that bite. This layer does not involve a model and does not need one to be useful.
2. The model explains. It is given the SQL, the relevant slice of your schema catalog, and the validator's findings, and asked to explain what the batch does, call out the risks, and address each finding. The answer comes back with the list of catalog objects it was built from.

Anchoring the narrative to findings is what keeps it from drifting into confident-sounding generalities about SQL. If the validator found nothing, the model is told that too.

The dialog is still unmissable

Requiring AI review also forces the confirmation dialog for every data-changing batch on that connection, so the rule-based bottom line - WE WILL MAKE UPDATE AND DELETE CHANGES. - is in front of you whatever the model says. The explanation is there to inform the decision, never to make it: a review cannot approve a batch, and a model being unavailable does not quietly drop the gate.

In progress: the gate, the deterministic findings, the grounded prompt, and the dialog are in place; connecting the explanation to each model backend is the remaining work. Until then the review shows the rule-based summary.

Uses the same grounded model path as query summarization. Related: refusing UPDATE/DELETE with no WHERE.