Structural and behavioral modelling of the possibility of unknown (or pending variable) objects rather than concrete ones

In the following, I provide an abstract description of my problem, as it will be more complicated if I provide the context and the specific code.

I have a Class Specification. A file reader accesses specific nested specifications from a file and furnishes a Specification instance correspondingly. The file may contain incomplete specifications, i.e. some values are to be bound later (for example, from a user input).

class Specification{
    Criteria spec1;
    AnotherCriteria spec2;
    ...
}

Now consider the interface:

Interface Criteria {
    criteriaMethod1();
    criteriaMethod2();
}

And consider the implementing class:

class ConcreteCriteria1 implements Criteria{
    someDataMember;
    @Overrride
    criteriaMethod1(){
        // some implementation goes here
    }
    @Overrride
    criteriaMethod2(){
        // some implementation goes here
    }
}

Now let's consider a class responsible for performing some specific tasks depending on a Criteria passed:

class WorkExcuter {
    doSomeWork(Criteria criteria);
}

I have a case, in such the criteria passed to doSomeWork is unknown, for example, in a waiting state to get some input from the user. This unknown state forces some specific additional attributes, for example, it's a maximum lenght of characters, an identifier, a waiting time, etc. To model that, let's consider that we have:

Interface ReuqiredInput {
    reuqiredInputMethod1();
}

Problem:

I want an 'intelligent' way (e.g. some design pattern) to make both, Specification (in spec1 data memebr) and doSomeWork accept ReuqiredInput instead of Criteria when the state is unknown as described. So they should accept both cases: either Criteria, or RequiredInput.

Possible ways around:

• Make ConcreteCriteria1 implement ReuqiredInput, in addition to Criteria; i.e., having a single concrete class implementing both interfaces; but then, I will have my concrete class as an ugly XOR between two different sets of elements that have nothing to do with each other and it has to have a method that figures out which set of elements is filled (to avoid exceptions as the other set will be null), and it complicates the access via the implemented interfaces.

• Overload doSomeWork; so that:

  class WorkExcuter {
      doSomeWork(Criteria criteria);
      doSomeWork(RequiredInput input);
  }
  
  

  But that solves the behavior part, but not the structural part, i.e. How to convince Specification that it can accept data member in sepc1 of type RequiredInput instead of Criteria?