I have the impression that - as a service operator - you want to give the answer 'Qualified but...' because it's feasible, however with impact / work to do.
We use today towards BSS the values/status's OK (qualified), OKBUT, NOK (unqualified).It would indeed be interesting to have a standard approach to indicate this OKBUT.As Ludovic indicates, two different paths for this.1) OR conditionallyQualified - this looks closer to our "OKBUT"
2) OR via alternate constructionTo me it sounds like this is maybe not really an alternate because there's only one way, via the existing access to do it, but both - I agree with Ludovic's view - approaches are acceptable.
In both cases we need a standard way to indicate the later "fully qualified date" + the reason and/or the work to do / impact + maybe even also a way of estimatedWork or estimatedCost to achieve this.
Anyway, I think it would be good to standardize a bit this response of "OKBUT" rainy day use case.