Creating And Using Stages

Stages can be managed centrally (i.e. registered once and updated dynamically) or locally within the application. Stages consist of Rulesets that are applied during one invocation. A stage can be composed of multiple rulesets, each executed independently and defined as a prioritized list (i.e. order matters). The Action for the ruleset with the highest priority is chosen for composing the response.

All stages must have names and belong to a project. The project ID is required to create a stage. The stage ID is returned when the stage is created and is required to invoke the stage. Optionally, you can provide a description of the stage.

​

Creating a Stage

To create a stage, you can use the following code snippet:

import galileo_protect as gp

gp.create_stage(name="my first stage", project_id="<project_id>", description="This is my first stage", type="local")  # type can be "central" or "local", default is "local"

If you’re using central stages, we recommend including the ruleset definitions during stage creation. This way, you can manage the rulesets centrally and update them without changing the invocation code.

import galileo_protect as gp

gp.create_stage(name="my first stage", project_id="<project_id>", description="This is my first stage", type="central", prioritized_rulesets=[
    {
        "rules": [
            {
                "metric": "pii",
                "operator": "contains",
                "target_value": "ssn",
            },
        ],
        "action": {
            "type": "OVERRIDE",
            "choices": [
                "Personal Identifiable Information detected in the model output. Sorry, I cannot answer that question."
            ],
        },
    },
])

If you’re using local stages, you can define the rulesets within the gp.invoke() function during the invocation instead of the create_stage operation.

​

Defining and Using Actions

Actions define the operation to perform when a ruleset is triggered when using Galileo Protect. These can be:

1. Override Action: The override action allows configuring various choices from which one is chosen at random when all the rulesets for the stage are triggered.

2. Passthrough Action: The pass-through action does a simple pass-through of the text. This is the default action in case no other action is defined and used when no rulesets are triggered.

​

Subscribing to Events for Actions

Actions include configuration for subscriptions which can be set to event destinations (like webhooks) to HTTP POST requests notifications are sent when the ruleset is triggered. Subscriptions can be configured in actions of any type as:

"action": {
    "type": "OVERRIDE",
    "choices": [
        "Personal Identifiable Information detected in the model output. Sorry, I cannot answer that question."
    ],
    "subscriptions": [{"url": "<your-webhook-url>"}],
}

By default, notifications are sent to the subscription when they are triggered, but notifications can be sent based on any of the execution statuses. In the below example, notifications will be sent to the specified webhook if there’s an error or the ruleset is not triggered.

"action": {
    "type": "OVERRIDE",
    "choices": [
        "Personal Identifiable Information detected in the model output. Sorry, I cannot answer that question."
    ],
    "subscriptions": [{"statuses": ["error", "not_triggered"], "url": "<your-webhook-url>"}],
}

The subscribers are sent HTTP POST requests with a payload that matches the response from the Protect invocation and is of schema:

{
  "text": "string",
  "trace_metadata": {
    "id": "string",
    "received_at": 0,
    "response_at": 0,
    "execution_time": -1
  },
  "status": "string"
}