PassResult and FailResult

Lesson 6 combined validators other people wrote. Before writing one of your own, it is worth seeing the two objects every validator hands back, because everything the Guard does afterwards is decided by what is inside them.

from guardrails.validators import FailResult, PassResult

fine = PassResult()
bad = FailResult(
    error_message="The reply promises a refund.",
    fix_value="We can offer store credit on order 8821.",
)

print(fine.outcome)
print(bad.outcome, "|", bad.error_message)
print(bad.fix_value)

A validator returns one of those two and nothing else. PassResult usually carries no information at all; the interesting one is FailResult.

error_message is the sentence a human reads in the summaries from lesson 4, and it is also the sentence Guardrails sends back to the model when a rule asks for another attempt. Writing a vague one costs you twice.

fix_value is the repaired value. It is optional, and it is what makes the difference between a rule that can only object and a rule that can put things right. Lesson 10 is built on it.

The whole shape

from guardrails.validators import FailResult

print(list(FailResult.model_fields))

error_spans marks the exact characters that offended, which lesson 21 uses while an answer is still arriving. validated_chunk and metadata belong to the same streaming machinery.

A keyword that is silently ignored

The Custom validators page has an example that returns a repaired value under the name on_fix. FailResult is a pydantic model, and a pydantic model drops keyword arguments it does not recognise.

from guardrails.validators import FailResult

wrong = FailResult(error_message="The reply promises a refund.", on_fix="store credit")

print(wrong.fix_value)
print(wrong.model_extra)

No error and no warning. The repair you wrote is gone, fix_value stays empty, and a validator configured to repair has nothing to repair with. Lesson 10 shows what the Guard hands you when that happens, because the symptom is nothing like the cause.