A stage can be composed of multiple rulesets, each of which is 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. Stages can be managed centrally (i.e. registered once and updated dynamically) or locally within the application.

​
Different Types of Stages

DimensionCentralLocal
Ruleset DefinitionDuring stage creation (i.e. gp.create_stage step) before invocation.Within the gp.invoke function, during the invocation.
Stage VersioningCentral stage definitions can be updated and applied to all future invocations.New versions are created to match the ruleset definitions within the invocation.
Stage ManagementCentral stage updated by using gp.update_stage.Local stages definitions can be updated in the gp.invoke invocation.
Stage Pause / ResumptionCentral stage definitions can be paused and resumed.Local stages are created and invoked can be paused or resumed.

​
When should I use central vs local stages?

We recommend using Central Stages, if:
  • You want to allow non-application developers to update your Protect configuration
  • You want to be able to dynamically update your Protect configuration on the fly. Without having to wait for code reviews or deployments.
We recommend using Local Stages, if:
  • You’re an application developer and are setting up Protect for the first time on your project. We find it’s always easier to iterate through code.
  • You want changes to your Protect configuration to go through the same code-review, release and deployment process as the rest of your application.