Creating And Using Stages
Learn to create and manage stages in Galileo Protect, enabling structured AI monitoring and progressive error resolution throughout the deployment lifecycle.
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:
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.
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:
-
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.
-
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:
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.
The subscribers are sent HTTP POST requests with a payload that matches the response from the Protect invocation and is of schema:
Was this page helpful?