What would be alternative ways to model IConvention?
First of all, the combination of a Specification and another method is not that unusual - it's called the Tester-Doer Pattern (although to be fair, I'm not sure whether it's a bona-fide pattern, as I've never seen it described outside of .NET). Even so, despite the precedence, I completely understand why you dislike the Temporal Coupling it implies. So which alternatives are available?

The first refactoring we could apply is to change the definition of IConvention to emply a Maybe monad. Assuming that we've defined a Maybe&lt;T&gt; class, IConvention now looks like this:

public interface IConvention
{
    Maybe&lt;IConventionInstance&gt; CreateInstance(Item item);
}


This would allow you to in a type-safe way to check whether or not an IConventionInstance instance could be created from the item.

However, once you realize that a Maybe monad really is nothing more than a special case of IEnumerable, you could consider refactoring IConvention once more:

public interface IConvention
{
    IEnumerable&lt;IConventionInstance&gt; CreateInstances(Item item);
}


In the normal implementation, an implementation would return zero or one item.

This would make the ConventionInstanceSelector and IConventionInstanceSelector types redundant (always a good thing), and you could implement the ModelReader class like this (caveat: I haven't tried to compile it):

public class ModelReader {
    IEnumerable&lt;IConvention&gt; _conventions;

    public ModelReader(IEnumerable&lt;IConvention&gt; _conventions) {
        _conventions = conventions;
    }

    public Model Read(IEnumerable&lt;Item&gt; items) {
        var model = new Model();

        var conventionInstances = from item in items
                                  from c in _conventions
                                  from ci in c.CreateInstances(item)
                                  select ci;
        foreach(var ci in conventionInstances) {
            ci.ApplyTo(model);
        }

        return model;
    }
}