MongoDB 9.0 adds a new validationLevel: "constraint" (SPM-4372). Unlike strict, it guarantees every document in the collection matches the validator, and the server enforces that guarantee by rejecting both validator changes and bypassDocumentValidation while it is in effect.

Compass's schema validation tab hardcodes ValidationLevel as 'off' | 'moderate' | 'strict', so a constraint collection renders a blank Level dropdown and still offers Edit rules. Applying a change then fails server-side with Validator cannot be changed when Validation level is 'constraint'.

There is a second affected state. Upgrading to constraint is a two-step collMod }}workflow, and the intermediate {{prepareConstraintValidationLevel: true state locks the validator in exactly the same way while validationLevel still reads "strict". Per the project's technical design, a crashed, failed, or interrupted upgrade leaves a collection in that state indefinitely with no automatic cleanup, so it is a state users will encounter in the wild. mongodb-data-service currently drops this field when shaping collection info, so Compass cannot see it at all.

Scope

• Widen ValidationLevel to include 'constraint' and surface it in the Level selector as a display-only option (Compass does not drive the two-step upgrade).
• Surface prepareConstraintValidationLevel through mongodb-data-service's collectionInfo.
• Track the lock as a tri-state (none / active / prepared) in the schema-validation edit mode; make the validator read-only in both locked states, with a warning banner naming the appropriate remedy — lower the level to strict, or clear the prepared flag via collMod.
• Widen the validation_level telemetry union.
• Unit coverage plus e2e coverage in collection-validation-tab.test.ts, gated on server >= 9.0.