XSD 1.1 xs:override and instance-document rollback: can a pipeline validate against two schema generations safely?

We run a validation pipeline where a base schema (base.xsd) and a derived XSD 1.1 schema (derived.xsd) coexist. The derived schema uses xs:override to tighten a complexType with an xs:assert, and it also adds a new member to an existing substitution group. Instance documents are produced against derived.xsd, but on a failed deployment we need to re-validate stored instances against base.xsd as a rollback path.

The uncertainty is at the boundary between the two schema generations: instances that exercise the new assertion or the new substitution group member appear to have no defined downgrade behavior in the XSD 1.1 specification, and I cannot find any normative compatibility metadata that a processor (Xerces-J or Saxon-EE) could consult to decide whether a given instance is safe to re-validate against the older schema.

Constraints: we cannot change the targetNamespace (that would force a full migration of all stored documents), and we want to avoid xs:redefine since it is deprecated in XSD 1.1. Wildcards with processContents="lax" exist in some types but do not cover the overridden type.

Specifically:

• Is there any defined XSD 1.1 mechanism for a processor to detect that an instance depends on an overridden construct before rollback validation is attempted?
• Does adding a substitution group member in the derived schema make rollback of the head element's content model formally unsafe, or only when instances actually use the new member?
• Is an external transform step (e.g., XSLT downgrade) the accepted practice here, or is there a schema-design pattern that keeps both generations compatible?