Workflows and Rules

Overview

The Risk Workflow Management CLI provides tools for managing fraud detection workflows and rules. All commands follow the pattern canso workflows ...

Prerequisites

• Set GRU_TOKEN environment variable for authentication

• Valid JSON configuration files for workflow and rule creation/updates

Workflow Management Commands

List Workflows

# List all workflows
canso workflows list

# List only active workflows
canso workflows list --is_active=true

# Get specific workflow details
canso workflows list --workflow_name=<workflow-name>

Create Workflow

canso workflows create <workflow-name> --config <path/to/workflow_config.json>

Sample workflow_config.json:

{
    "description": "Workflow for detecting credit card fraud",
    "initial_rules": [
        {
            "rule_name": "amount_limit_check",
            "operator": "AND",
            "sub_rules": [
                {
                    "field": "amount",
                    "operator": "<",
                    "redis_key": "transaction_limit",
                    "redis_field": "user:{user_id}"
                }
            ]
        }
    ]
}

Update Workflow Status

canso workflows update-status <workflow-name> --status [ACTIVE|INACTIVE|DEPRECATED]

Workflow status changes are tracked only in the control plane database. Future versions may implement rollouts in the data plane via ARGOCD.

Deploy Workflow

canso workflows deploy <workflow-name> --env [BACKTESTING|STAGING|PRODEXPERIMENT|LIVE] --cluster_name <cluster-name> --namespace <namespace> 

The following environment variable can be set using the --env_vars flag:

    FEATURE_STORE_HOST: str 
    FEATURE_STORE_PORT: int     
    FEATURE_STORE_DB: int   
    FEATURE_STORE_USERNAME: str
    FEATURE_STORE_PASSWORD: str

NOTE: By default, the feature store is connected to the deployed Redis instance along with the Helm chart.

Example:

--env_vars FEATURE_STORE_HOST=localhost,FEATURE_STORE_PORT=6379,FEATURE_STORE_DB=1,FEATURE_STORE_USERNAME=admin,FEATURE_STORE_PASSWORD=admin

Providing HPA Configuration

You can customize the Horizontal Pod Autoscaler (HPA) settings by providing your own configuration file with the --hpa_configs flag. Below is an example of what the configuration file look like:

Sample hpa_config.json:

{
    "min_replicas": 1,
    "max_replicas": 8,
    "target_cpu_utilization_percentage": 80,
    "target_memory_utilization_percentage": 80
}

To deploy a workflow with your custom HPA settings, use the following command:

canso workflows deploy <workflow-name> --env [BACKTESTING|STAGING|PRODEXPERIMENT|LIVE] --cluster_name <cluster-name> --namespace <namespace> --hpa_configs <path/to/hpa_config.json>

If you don’t provide an HPA configuration file, the system will automatically use the default settings.

Rule Management Commands

List Rules

# List all rules in a workflow
canso workflows rules list <workflow-name>

# List rules with specific stage
canso workflows rules list <workflow-name> --stage <STAGE>

# Get specific rule details
canso workflows rules list <workflow-name> --rule_name <rule-name>

Available stages: REGISTERED, BACKTESTING, STAGING, PRODEXPERIMENT, LIVE

Create Rule

canso workflows rules create <workflow-name> --config <path/to/rules_config.json>

Sample rules_config.json:

{
    "rule_name": "amount_limit_check_2",
    "operator": "AND",
    "sub_rules": [
        {
            "field": "amount",
            "operator": "<",
            "redis_key": "transaction_limit",
            "redis_field": "user:{user_id}"
        }
    ]
}

Update Rule

# Update rule definition
canso workflows rules update <workflow-name> <rule-name> --config <path/to/rule_def.json>

# Update rule status
canso workflows rules update <workflow-name> <rule-name> --status [ACTIVE|INACTIVE|DEPRECATED]

# Update rule stage
canso workflows rules update <workflow-name> <rule-name> --stage [REGISTERED|BACKTESTING|STAGING|PRODEXPERIMENT|LIVE]

Sample rule_def.json:

{
    "operator": "AND",
    "sub_rules": [
        {
            "field": "amount",
            "operator": "<",
            "redis_key": "transaction_limit",
            "redis_field": "user:{user_id}"
        }
    ]
}

Common Fields

Rule Operators

• AND: All sub-rules must pass

• OR: At least one sub-rule must pass

Sub-Rule Operators

• <: Less than

• >: Greater than

• ==: Equal to

• !=: Not equal to

• >=: Greater than or equal to

• <=: Less than or equal to

Rule Stages

1. REGISTERED: Initial state for new rules

2. BACKTESTING: Under testing with historical data

3. STAGING: Testing in non-production environment

4. PRODEXPERIMENT: Limited production testing

5. LIVE: Active in production

Status Values

• ACTIVE: Rule/workflow is enabled

• INACTIVE: Rule/workflow is disabled

• DEPRECATED: Rule/workflow is no longer in use