After some thought, I have concluded that the ideal way to enforce typing and provide error checking is to make such error checking automatic, with a provision that allows the storybuilder to disable error checking and poison. Thus, I envision a basic level of poison in the interpreter, which I shall call Level 1 poison, that rangechecks every input to every function call. If the input value falls outside the acceptable range, then the interpreter will poison the results by returning a NonValue for the function. NonValues themselves are defined to fall outside the acceptable range of input values; thus, a bad input will propagate NonValues down the entire sequence of affected calculations. Whenever a NonValue is stored into any of the consequence outputs (NewDirObject, NewIndObject, NewThirdObject, NewFourthObject, or Weight), the interpreter will set the Weight of the affected consequence to -1, a value that tells the engine that this consequence may not be selected under any circumstances.
The only remaining question is, should the storybuilder have any access to or control over the poison process? There are two possibilities here: that the storybuilder would want to disable poison, and that the storybuilder would want to know and respond if poison is invoked.
In the first case, I can see no circumstances under which a storybuilder could safely disable poison. If, for example, the storybuilder wishes her character to offer a deal, and the character in question has nothing to offer, then there is no circumstance where that offer might still make sense. Yes, the storybuilder can include other options, with other weighting values. That way, if the preferred approach is poisoned, the action will resort to the next best option. We don't need no stinking IF-statements that way, either.
In the second case, the storybuilder should simply anticipate the possibility of poisoning occurring and prepare alternatives for that contingency. If no alternatives are available, then nothing happens. Either way, the system is just about as clean and simple as it can be.
On another line of thought, should we eliminate the datatype "anything" and replace it with a shapeshifter datatype that assumes the datatype of whatever value it receives? This would apply only to the substitution variables, eliminating their value as datatype-defeaters. Hmm... what about the role of ThirdObject and FourthObject in that case?