From some quick testing, I believe this validation will always fail to pass. The reason is that newModel is a generic Model class object. When the validator tries to make a validation call to the service, it will call the doInfer function within the proper service class. These functions will check that the model is of the expected service-specific <ServiceName>Model class (example of this check for JinaAI) which will always be false and will throw an exception that fails validation. In order for validation to pass, the model provided to the validator must be of the service-specific type. There are a few options I can think of for accomplishing this:

1. You can convert the Model back to an UnparsedModel (through a process like ModelRegistry.modelToUnparsedModel function) and then run it through the parsing logic of the service (through a parsePersistedConfigWithSecrets call). I don't believe this is the best way to accomplish this as it involves unnecessary deserialization/re-serialization.
2. You can update the logic within combineExistingModelWithNewSettings to take the existingUnparsedModel instead of the existingParsedModel and run the updates on the various settings while they are still unparsed. Then use parsePersistedConfigWithSecrets on the updated UnparsedModel object to get a service-specific model object for validation. I would recommend looking into this option first.
3. We can move the combineExistingModelWithNewSettings into a more service specific location. This may be within the individual service specific models or may just be in the service implementations. This will likely require defining it separately for each service implementation which may be a significant rework so I would try option 2 before considering this route.

Let me know if you have any questions about this. I've also added a comment about testing in the issue linked in the description as I think we will want some tests to ensure this logic is functioning properly.