rototo
Examples

Example: Ship an Operational Override Without Redeploying

This example models an operational override that can move through the config repository and be picked up by running services after refresh.

Use this pattern when operators need to change visible behavior quickly but the change still needs review, validation, promotion, refresh, and observability.

Production problem

During a payment provider incident, users in affected countries should see a checkout banner. Everyone else should see no banner.

The application resolves:

checkout-banner

and receives a small structured object.

Workspace shape

config/
  rototo-workspace.toml
  schemas/
    context.schema.json
    banner.schema.json
  qualifiers/
    affected-payment-region.toml
  variables/
    checkout-banner.toml

Qualifier

Create qualifiers/affected-payment-region.toml:

schema_version = 1

[qualifier]
description = "Requests from regions affected by the payment provider incident"

[[qualifier.predicate]]
attribute = "request.country"
op = "in"
value = ["DE", "FR", "NL"]

Variable

Create variables/checkout-banner.toml:

schema_version = 1

[variable]
description = "Checkout banner shown during operational incidents"
schema = "../schemas/banner.schema.json"

[variable.values.none]
enabled = false
message = ""
severity = "info"

[variable.values.payment_incident]
enabled = true
message = "Some payment methods may be delayed. Card checkout is still available."
severity = "warning"

[variable.env._]
value = "none"

[variable.env.prod]
value = "none"

[[variable.env.prod.rule]]
description = "Show the payment incident banner in affected regions"
qualifier = "affected-payment-region"
value = "payment_incident"

Verify the behavior

rototo variable resolve checkout-banner \
  --workspace config/ \
  --env prod \
  --context '{"request":{"country":"DE"}}' \
  --json

Expected selected key:

payment_incident

Tests to keep

Test one affected country and one unaffected country. Also test the shape of the returned object so the application never receives a banner without enabled, message, and severity.

Production behavior

Deploy the application with a movable workspace source such as a production branch. After the config change is reviewed and that ref moves, running services can pick up the new banner on refresh.

Fit

Use this for short-lived operational behavior that must be controlled outside application deploys.

Do not use it for messages that need a content-management workflow, rich localization, approvals beyond code review, or non-engineering editing.

Related docs