At Portkey, we believe in helping you make your workflows as modular as possible. This is useful when:

  • You want the same Guardrail checks but want to take different basic actions on them
  • Your Guardrail checks definitions are dependent on an upstream task and are updated in code
  • You want greater control over how you want to handle Guardrails

With the Raw Guardrails mode, you can achieve all this.

​
Example of a Raw Guardrail

"before_request_hooks": [{
    "type": "guardrail",
    "id": "my_solid_guardrail",
    "checks": [{
      "id": "default.regexMatch",
      "parameters": {
        "regex": "test"
      }
    }]
}]

In this example:

  • type: Specifies the type of hook, which is guardrail.
  • name: Gives a name to the guardrail for identification.
  • checks: Lists the checks that make up the guardrail. Each check includes an id and parameters for the specific conditions to validate.

​
Configuring Guardrail Actions

"before_request_hooks": [{
    "type": "guardrail",
    "id": "my_solid_guardrail",
    "checks": [{
      "id": "default.regexMatch",
      "parameters": {
        "regex": "test"
      }
    }],
    "deny": false,
    "async": false,
    "on_success": {
        "feedback": {"value": 1,"weight": 1}
    },
    "on_fail": {
        "feedback": {"value": -1,"weight": 1}
     }
}]

In this example,

  • deny: Is set to TRUE or FALSE
  • async: Is set to TRUE or FALSE
  • on_success: Used to pass custom feedback
  • on_failure: Used to pass custom feedback