Name the engine and the actual change

Record the database engine and version, intended target, exact migration files or commit, expected schema and data effect, and application versions that must remain compatible. “Add an index” is not a sufficient plan. The engine-specific command, table shape, data volume, write traffic, transaction boundary, and maintenance constraints can change the risk. The local receipt checks only that an engine is declared; the human reviewer must determine whether its version and behavior are actually understood.

PostgreSQL's CREATE INDEX documentation illustrates why a generic answer is unsafe. Ordinary and concurrent index creation have different locking, transaction, duration, and failure behavior; a failed concurrent build can leave an invalid index. Those details are a PostgreSQL example, not a recipe for another engine.

Separate a bounded exercise from production proof

Run the narrowest safe non-production exercise that can expose an incorrect assumption. Record the fixture, engine version, command, input boundary, observed result, and what the exercise did not resemble. A staging run can be useful evidence without proving production duration, lock contention, data correctness, or recovery.

Do not silently grant a coding agent credentials to a live database to “check” the migration. Keep target selection, access, scheduling, and failure response with named humans under the team's existing operating policy.

Require compatibility and recovery decisions

Before any production schedule, name whether old and new application versions can coexist and whether the response to a problem is pause, forward repair, application rollback, data recovery, or a maintenance window. Application rollback is not automatically database rollback. If transformations or destructive changes are involved, record who owns recovery before the change starts.

Use an inspectable admission receipt

The local evidence/P96/migration-admission.mjs fixture requires an exact commit, engine, target, scope, compatibility plan, recovery owner, bounded exercise, and exact-commit review. It rejects a staging result framed as proof of production safety:

npm test --prefix sites/odexing.com/evidence/P96

It is a receipt validator, not a migration runner, SQL parser, lock estimator, or deployment authorization system.

Deployment checklist

  • The exact engine, version, target, and migration commit are named.
  • The expected schema and data effect have a bounded scope.
  • Compatible application-version assumptions are documented.
  • A non-production exercise is recorded with its limitations.
  • A named maintainer owns recovery and production scheduling.
  • The reviewer accepts the exact commit, not an earlier or later diff.

Does a passing staging migration mean production is safe?

No. It proves only the recorded exercise. Production data, traffic, locks, permissions, dependent services, and timing can differ materially.