Observed behaviour
GuardianCheck (deprecated since v0.4) implemented the Requirement.validate() interface, which meant it could be passed directly to RepairTemplateStrategy and m.validate() / m.instruct(..., requirements=[...]). Example from docs/examples/safety/repair_with_guardian.py:
guardian = GuardianCheck(GuardianRisk.FUNCTION_CALL, thinking=True, tools=tool_schemas)
result = m.instruct(prompt, requirements=[guardian], strategy=RepairTemplateStrategy(loop_budget=3))
The thinking=True mode also populated ValidationResult.reason with the Guardian chain-of-thought string, which RepairTemplateStrategy injected back into the repair prompt as targeted feedback.
Expected behaviour
A Requirement subclass backed by the Guardian Intrinsics API (guardian_check(), policy_guardrails()) that can be dropped into the same requirements= slot and used with RepairTemplateStrategy.
Why this gap exists
Guardian Intrinsics return a float score (0.0–1.0) with no reasoning string. There is no direct drop-in for the GuardianCheck-as-Requirement pattern. Because of this, the repair_with_guardian.py example was removed in #935 (Guardian docs migration) rather than migrated, and docs/examples/safety/README.md documents the gap explicitly.
A new Requirement subclass would need to:
- Accept a
criteria key (from CRITERIA_BANK or custom string), a threshold float, and a configured AdapterMixin backend
- Call
guardian_check() and return ValidationResult(result=score < threshold, ...)
- Accept
policy_guardrails() as an alternative path for policy compliance checks
The absence of a reasoning string means repair feedback will be less targeted than GuardianCheck(thinking=True) was — this is a known trade-off worth documenting.
Related
Observed behaviour
GuardianCheck(deprecated since v0.4) implemented theRequirement.validate()interface, which meant it could be passed directly toRepairTemplateStrategyandm.validate()/m.instruct(..., requirements=[...]). Example fromdocs/examples/safety/repair_with_guardian.py:The
thinking=Truemode also populatedValidationResult.reasonwith the Guardian chain-of-thought string, whichRepairTemplateStrategyinjected back into the repair prompt as targeted feedback.Expected behaviour
A
Requirementsubclass backed by the Guardian Intrinsics API (guardian_check(),policy_guardrails()) that can be dropped into the samerequirements=slot and used withRepairTemplateStrategy.Why this gap exists
Guardian Intrinsics return a
floatscore (0.0–1.0) with no reasoning string. There is no direct drop-in for theGuardianCheck-as-Requirementpattern. Because of this, therepair_with_guardian.pyexample was removed in #935 (Guardian docs migration) rather than migrated, anddocs/examples/safety/README.mddocuments the gap explicitly.A new
Requirementsubclass would need to:criteriakey (fromCRITERIA_BANKor custom string), athresholdfloat, and a configuredAdapterMixinbackendguardian_check()and returnValidationResult(result=score < threshold, ...)policy_guardrails()as an alternative path for policy compliance checksThe absence of a reasoning string means repair feedback will be less targeted than
GuardianCheck(thinking=True)was — this is a known trade-off worth documenting.Related
repair_with_guardian.py; this gap is documented indocs/examples/safety/README.mdRequirementbacked by intrinsics; partially overlaps this issuemellea/stdlib/requirements/safety/guardian.py— existing (deprecated)GuardianCheckimplementation for referencemellea/stdlib/components/intrinsic/guardian.py— currentguardian_check()andpolicy_guardrails()signatures