Rails migration rollback scope: restoring schema without expecting deleted data back

Rollback scope after a schema change

I am defining a rollback policy for a Rails application (assume a current Rails 7.x line with PostgreSQL) and need to pin down exactly what rails db:rollback is allowed to promise. Our migrations are written with change where possible, but some use remove_column, change_column, and occasionally execute for data cleanup.

Constraints and uncertainty

My understanding is that reversibility is structural only: Rails can recreate a dropped column if enough type information is present, but rows deleted or transformed by the migration are not restored. Operations like raw SQL or ambiguous column changes raise ActiveRecord::IrreversibleMigration unless I write explicit up/down or reversible blocks. What I cannot settle is the policy boundary: should rollback be defined as "schema compatible with the previous code version" or as "full pre-migration state," given that the latter seems unachievable for destructive changes without separate backups?

Questions

• Is schema-only restoration the correct documented expectation for db:rollback, with data recovery delegated to backups?
• Which operations in my set (remove_column without options, change_column, execute) must be rewritten as up/down to avoid an irreversible rollback at runtime?
• Does the expand/contract pattern remove the need for data-restoring rollbacks entirely, or only narrow the window where they matter?