> Consider this: it doesn't address the `self` person at all.

This is a good principle to note, but I don't think that the alternative is better in this case. If we had a separate subclass of `ResponseSet`, putting it that subclass would make sense.

For this case, I think that neither `Person` nor `ResponseSet` is the right place. Why not have it on the context itself? This could be handled one of two ways:

* `MakeIneligible#run` could be a no-op if it wasn't appropriate to make the person ineligible
* `MakeIneligible` could have a factory method that would return an instance IFF it should apply to a a passed-in `ResponseSet`.

I prefer the latter, but either would work. Ex. for the latter:

```
class MakeIneligible
  def self.create(response_set)
    if makes_person_ineligible?(response_set)
      new([...])
    else
      nil
    end
  end
end
```

Then in the controller you'd have something like:

```
[
  MakeIneligible
].collect { |context| context.create(response_set) }.compact.each { |context| context.run }
```

Supporting a list of contexts is possible YAGNI territory, but I think that generalizing helps to think about where the seams are in this case.