Your Problem 2 is indeed a promise problem. It is not in NP, but if you like, you can say that it's in a class Promise-NP. (This term doesn't seem very common, though, unlike the other class "Promise-BPP".)

See Oded Goldreich's survey [*On Promise Problems*](http://www.wisdom.weizmann.ac.il/~oded/prpr.html). The promise classes are different, and sometimes much stronger, than their plain versions. Among other things, a problem in the promise version of NP∩co-NP need not be in NP, and (as commented [here](http://blog.computationalcomplexity.org/2006/07/definitions-of-advice.html#115259881395001905)) there are NP-hard problems in promise-NP∩co-NP while this is not believed to be the case for NP∩co-NP.

Edit (in response to first comment below): Well, because you've constrained your input, so you're no longer working with the same model. In decision problems, *all* possible input strings are either YES instances or NO instances, whereas in promise problems, strings are allowed to be "invalid": neither YES nor NO. NP is a class of decision problems, in which for all YES instances there is a succinct certificate, and *only* for them. For your Problem 2, although there is a succinct certificate for the YES instances, *if* given an input which does not satisfy the condition, there may still exist some "certificate" that makes whatever verification you were doing accept the input. So the sets of strings accepted and rejected by your predicate will be supersets of the actual YES and NO instances respectively (and have intersection with the "invalid" instances). Sorry if this is unclear; all this is explained better in the first few pages of the survey linked above.