AI-generated illustration. Generating a migration, approving its technical evidence, and authorizing production execution are separate permissions; none substitutes for the others.
An AI-generated database migration should have a named human owner, independent technical review, and explicit production release authorization. Permission to generate it is not permission to approve it. Passing tests and an application rollback plan are not, by themselves, proof of data safety.
For engineering leaders adopting AI coding tools, the decision is which changes the team can verify, who accepts their consequences, and when missing evidence must block release.
This is a proposed policy template, not a claim that any tool can establish migration safety. Apply it to human-written migrations too: the consequences depend on the operation, not its author.
Separate three permissions
Treat these as distinct grants of authority:
| Permission | What it allows | What it does not allow |
|---|---|---|
| Tool use | Draft migration code and review materials within approved data-access boundaries | Grant production credentials, approve correctness, or authorize execution |
| Technical approval | Accept a specific migration artifact and its verification evidence | Schedule or execute it against production data |
| Production release | Authorize the approved artifact under stated operating and recovery conditions | Replace missing technical evidence or approve a materially changed artifact |
The migration owner explains the intended transformation, collects evidence, and resolves failures. That accountability remains even if the tool wrote every line.
A technical reviewer other than the author challenges assumptions and assesses database behavior. When a migration changes the meaning of stored data, name a data owner to approve that meaning. This may be a domain lead rather than a database specialist.
The release authority decides whether the approved change may run under current conditions. The executor, a person or automation identity, performs only the authorized operation.
These are responsibilities, not necessarily separate job titles. Destructive changes should not be self-approved by their author.
Classify by consequences, not syntax
Ask what can change, what can be lost, and what must remain available.
An additive change is not automatically low risk. Building an index or validating a constraint may create operational pressure, depending on the database engine, configuration, and workload. A backfill that overwrites the only copy of a value belongs in the destructive class, whatever its filename says.
Use the highest applicable class. Escalate when a change affects business-critical invariants, has uncertain execution behavior, or lacks a demonstrated recovery path.
Reusable migration approval matrix
| Change class | Owner and reviewers | Required evidence | Production release authority | Stop conditions |
|---|---|---|---|---|
| Additive schema change: new nullable field, new table, or another change intended to preserve existing data | Service owner; independent reviewer with relevant database knowledge | Compatibility across application versions that may coexist; data-invariant checks; representative workload rehearsal for locking, latency, and resource effects; validated fallback, including whether the addition can safely remain | Designated service release authority, within documented operating limits | Unknown compatibility; unassessed workload effects; fallback requires an unreviewed destructive operation |
| Backfill: populate new fields or records while retaining the source | Migration owner; database reviewer; data owner for transformation rules | Source-to-target rules; reconciliation and invariant checks; representative volume and workload rehearsal; interruption, restart, and concurrent-write behavior; validated repair or recovery procedure | Designated release authority, with operational coverage and stop criteria agreed beforehand | Unexplained mismatches; unknown concurrent-write handling; unproven restart or repair behavior; rehearsal exceeds agreed limits |
| Destructive transformation: drop, overwrite, truncate, narrow values, or collapse distinctions | Migration owner; database reviewer; accountable data owner accepting information loss | Applicable evidence from preceding classes, plus dependency review, explicit loss inventory, retention obligations, and recovery validation for affected data and dependent state | Separate destructive-release decision by the data owner and production release authority | Unresolved consumers; unapproved information loss; unknown treatment of post-backup writes; missing recovery evidence; unmet retention requirements |
A rehearsal must state its limits. Synthetic or appropriately de-identified data in an isolated environment can help exercise relevant distributions and edge cases. A tiny fixture cannot establish behavior at the intended scale or under concurrent load.
For a deliberately irreversible deletion, do not invent a rollback story. Require a separate decision accepting permanent loss and addressing applicable retention obligations. Until that decision exists, missing recovery remains a stop condition.
AI-generated illustration. In the hypothetical state merge, retaining the source preserves the distinction between queued and retry-wait records. Removing it leaves pending values that cannot, by themselves, reveal their original meaning.
Require evidence that challenges the implementation
An approval packet should answer four questions.
1. What must remain true? Define data invariants before assessing the generated implementation. Examples include unique business identifiers, preserved relationships, exact reconciliation of an accounting total, or valid domain-state transitions. “The migration completed” is not an invariant.
2. What behavior was exercised? Record the database version and relevant configuration, data characteristics, workload, migration artifact, and observed results. Include interruption and concurrent-write scenarios where applicable. State what the rehearsal did not cover.
3. What happens when a check fails? Set measurable operating limits before execution, based on service requirements and available capacity. Name who may halt the operation, explain what halting does, and specify how partially transformed data will be handled. Canceling a job does not necessarily restore its starting state.
4. How is recovery validated? Show that the procedure restores required data and application behavior within accepted time and data-loss limits. Address writes made after the recovery point and dependent changes, such as downstream records. A backup’s existence is not proof that recovery works.
AI-generated tests can contribute evidence, but they may encode the migration’s mistaken assumptions. Derive expected outcomes from independently reviewed domain rules, then check the transformation against them. Independence means a separate basis for correctness, not merely asking the same tool for another test.
Application rollback is a separate concern. Reverting code does not recreate overwritten values or deleted rows; deployment compatibility is not data recovery.
Example: merging two states into one
Consider a hypothetical service with two stored states, queued and retry_wait. A proposed migration introduces pending as their replacement.
Assume the distinction affects retry scheduling, application versions may coexist during deployment, and no other history reliably preserves the original state.
Rewriting both states to pending and dropping the old field destroys information. A passing test that checks only whether every row contains an allowed value would miss that consequence.
Apply the policy in three decisions:
- Approve the additive field separately. Require compatibility evidence for application versions that will coexist. Define which field is authoritative during the transition.
- Approve a source-preserving backfill. Require reconciliation against the agreed mapping, checks that unrelated values remain unchanged, and evidence that new writes cannot leave fields inconsistent. Rehearse interruption and repair using isolated test resources.
- Withhold approval to remove the old field. First require evidence that retry scheduling and other consumers no longer depend on the distinction. Then obtain a separate decision about information loss and recovery.
As a review exercise, ask: “After a failed cutover, how would we identify which pending records originally meant retry_wait, including records updated during the transition?”
If the approval packet cannot answer, block the destructive release unless permanent loss has been explicitly authorized and the remaining requirements are satisfied. The exercise tests whether the original meaning is recoverable, not merely whether the new schema is valid. Separating stages makes the decision visible. It does not automatically make the migration safe.
Renew approval when assumptions change
Use this compact record in the change request:
- Scope: migration artifact identifier, intended environment, affected objects, and risk class.
- Accountability: migration owner, technical reviewer, data owner where needed, release authority, and executor.
- Correctness: transformation rules, invariants, evidence links, observed results, and unresolved limitations.
- Operations: release prerequisites, monitoring, operating limits, halt authority, and partial-completion handling.
- Recovery: validated procedure, recovery limits, treatment of intervening writes, or explicit authorization of intended permanent loss.
- Decision: approved scope and conditions, blocked items, and separate destructive-release authorization where applicable.
Material changes to the migration, workload assumptions, transformation rules, or recovery procedure require renewed review. Before execution, verify that the artifact being run is the one approved.
Allow AI to help produce proposals within approved access rules. Grant execution authority only when the required evidence and approvals are in place. If evidence is missing, reduce the scope or postpone the change rather than treating confidence in the tool as permission to proceed.
Use this approval checklist as part of your evaluation of OpenThunder.