I haven’t had a ton of time to look into it, but I’m stumped why config.include Dry::Monads[:result] in the operations spec support file isn’t working. Even directly including include Dry::Monads[:result] directly in the spec isn’t working 
As for the other issue, you need to put step in front of the Success and Failure calls. This isn’t at all obvious though and we should make the ergonomics better. We should at least improve the documentation to talk about this gotcha. It’s quite weird to add step directly in front of Success and Failure constructors, so I’d re-work it to something like this:
module HanamiSample2
module Predictor
class CreatePrediction < HanamiSample2::Operation
def call(input)
step validate_input(input)
end
private
def validate_input(input)
if !input.nil? && !input.empty?
Success("Prediction created")
else
Failure("Invalid input")
end
end
end
end
end
By not adding step, it’s wrapping your result in Success. Instead of that, I think I’d prefer seeing a helpful error telling the user about step conventions. Additionally, this could be fixed at a lower level, by preventing all nested monads, e.g. Success(Failure(...)). It’s hard to reason about monads in a dynamic type system, so I feel like this is a reasonable trade-off to make it simpler for users.
I raised this suggestion previously and now we have a concrete use-case of it being confusing for someone else: https://discourse.hanamirb.org/t/extract-dry-result-with-guardrails/985