So, while we're on the topic, what are the direct thoughts on my design there? I.E. using a validator (and potentially throwing) from the constructor (the latter an idea I got from Scott Meyer, iirc) vs. constructing empty then compelling the user to fill in the blanks prior to calling run().
The reason I wanted to have the constructor do the validation and bomb gracefully upon a fail is that I want the interface here to be very difficult to use incorrectly, and there's (at least) two parts to that, which I see: fewer calls need to be made (less internals exposed) and it still prevents you from doing something bonkers (in my example there, you can't do any object-supported operations on your list of things if the place isn't valid).
I think that, were I to allow empty construction then push init responsibility to the user, there's not much of a difference: init() could throw instead of the constructor, and you'd still have an object in an empty/usable state. (That has some appeal.) I'm honestly not clear on what the right answer to this is.