# 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

```bash
# 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

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

Sample workflow\_config.json:

```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

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

{% hint style="info" %}

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

### Deploy Workflow

```bash
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:

```bash
--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:

```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:

```bash
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

```bash
# 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

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

Sample rules\_config.json:

```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

```bash
# 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:

```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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.canso.ai/risk/workflows.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.