Authorization Server and Resource Server OAuth token schema rollback compatibility

The goal is to guarantee that a change to the OAuth token store schema—such as adding a column or altering a data type—can be rolled back without causing validation failures for tokens that were issued before or after the change.

Constraints include the lack of a standardized schema‑version signal in the token introspection response, the need for both the Authorization Server (which writes tokens) and the Resource Server (which reads/introspects them) to tolerate the previous schema during the rollback window, and the variability of token‑store implementations across libraries and back‑ends.

Given these factors, what migration patterns ensure bidirectional compatibility? How can developers verify that tokens issued under the new schema remain validatable after reverting to the old schema without introducing version‑specific code? Are there safe defaults or nullable‑column strategies that eliminate the need for coordinated downtime?