Update docs/pipeline-components-and-applications/loaders-storage-targ…

…ets/bigquery-loader/upgrade-guides/2-0-0-upgrade-guide/index.md

Co-authored-by: Nick <[email protected]>

docs/pipeline-components-and-applications/loaders-storage-targets/bigquery-loader/upgrade-guides/2-0-0-upgrade-guide/index.md

@@ -84,7 +84,9 @@ To avoid crashing or losing data, BigQuery Loader 2.0.0 proceeds by creating a n
   - `9999999` is a hash code unique to the schema (i.e. it will change if the schema is overwritten with a different one).
 
 If you create a new schema `1-0-2` that reverts the offending changes and is again compatible with `1-0-0`, the data for events with that schema will be written to the original column as expected.
-
+:::tip
+You might find that some of your schemas were evolved incorrectly in the past, which results in the creation of these “recovery” columns after the upgrade. To address this for a given schema, create a new _minor_ schema version that reverts the breaking changes introduced in previous versions. (Or, if you want to keep the breaking change, create a new _major_ schema version.) You can set it to [supersede](/docs/understanding-tracking-design/versioning-your-data-structures/amending/index.md#marking-the-schema-as-superseded) the previous version(s), so that events are automatically validated against the new schema.
+:::
 :::note
 
 If events with incorrectly evolved schemas never arrive, then the recovery column would not be created.