# Example: Select Behavior for a Reviewed Account Class
This example models behavior selected for a named account class, with the
condition owned by the workspace instead of application branches or an external
rule system.
Use this pattern when a reviewed account class or request condition should
receive different behavior: enterprise accounts, internal users, countries,
regions, or tenants.
## Production problem
Payment reviews should use the standard queue by default in production, but
premium accounts in Germany should use a regional priority queue.
The application resolves one variable:
```text
payment-review-queue
```
The workspace owns the condition definition and the selection rule.
## Workspace shape
```text
config/
rototo-workspace.toml
schemas/
context.schema.json
qualifiers/
premium-germany.toml
variables/
payment-review-queue.toml
```
## Runtime context
The application supplies account and request facts:
```json
{
"account": {
"plan": "premium"
},
"request": {
"country": "DE"
}
}
```
Declare that shape in the context schema so rule paths are validated.
## Qualifier
Create `qualifiers/premium-germany.toml`:
```toml
schema_version = 1
[qualifier]
description = "Premium accounts making requests from Germany"
[[qualifier.predicate]]
attribute = "account.plan"
op = "eq"
value = "premium"
[[qualifier.predicate]]
attribute = "request.country"
op = "eq"
value = "DE"
```
The qualifier gives the account class a name. The variable can now use
`premium-germany` instead of repeating raw predicates.
## Variable
Create `variables/payment-review-queue.toml`:
```toml
schema_version = 1
[variable]
description = "Payment review queue"
type = "string"
[variable.values]
standard = "standard-review"
regional_priority = "de-priority-review"
[variable.env._]
value = "standard"
[variable.env.prod]
value = "standard"
[[variable.env.prod.rule]]
description = "Premium German accounts use regional priority review"
qualifier = "premium-germany"
value = "regional_priority"
```
## Verify the behavior
Matching context:
```sh
rototo resolve config/ -v payment-review-queue \
--env prod \
--context '{"account":{"plan":"premium"},"request":{"country":"DE"}}'
```
Non-matching context:
```sh
rototo resolve config/ -v payment-review-queue \
--env prod \
--context '{"account":{"plan":"free"},"request":{"country":"DE"}}'
```
The matching request should select `regional_priority`. The non-matching
request should select `standard`.
## Tests to keep
Test at least:
- matching account class satisfies all predicates;
- non-matching account class misses one predicate;
- context schema rejects a malformed request context.
## Fit
Use this when a named account class should receive different behavior and the
condition definition should be reviewed in configuration.
Do not use this pattern for percentage rollout. Use a bucket predicate for a
deterministic rollout bucket.
## Related docs
- [How to Select a Value for a Runtime Condition](how-to-select-a-value-for-a-runtime-condition.html)
- [How to Add a New Context Field](how-to-add-a-new-context-field.html)
- [Qualifier File Reference](qualifier-reference.html)
- [Predicate Reference](predicate-reference.html)