Rules Engine¶

The rules engine is a separate Workbench service that validates risks against configured rule groups. It can produce blocking errors or informational warnings, and is integrated into pipelines using a dedicated component type.

Overview¶

The rules engine runs as its own service (separate from the core Workbench services) and connects to its own database schema (rules_engine). It is triggered as a pipeline component:

{
  "name": "run_facility_validation",
  "componentType": "RUN_RULES_ENGINE",
  "attributes": {
    "groupName": "Facility Risk Validation"
  }
}

Rule groups¶

Rule groups are named sets of rules defined in config/{client}/rules/groups.json:

[
  { "groupName": "Facility Risk Validation", "schemeName": "facilityRisk" },
  { "groupName": "User Authority Limit Validation", "schemeName": "userAuthorityLimit" },
  { "groupName": "Quote Validation", "schemeName": "quoteValidation" }
]

Field	Description
`groupName`	Display name and reference used in pipeline components
`schemeName`	Links to a data mapping scheme in `rules/schemes.json`

Rule results¶

Rules can produce two outcome types:

Result	Behaviour
`ERROR`	Blocking — the action cannot be completed until the error is resolved
`WARNING`	Informational — displayed to the user but does not block submission

Environment configuration¶

The rules engine service URL and database connection are environment-specific values. They live in the DynamoDB environment profile (dynamodb/{env}/data.json) — edit these files directly in the config repository, then raise a Deploy DynamoDB Changes request in the Send Partner Portal. Business-level configuration (such as risk value flag mappings registered against be_config.json in S3) lives in the business config domain.

Confirm the exact keys for your active core platform version with your delivery lead — naming has evolved across versions.

Note

The rules engine URL and database URL differ per environment. Add them to dynamodb/{env}/data.json for each environment and raise a Deploy DynamoDB Changes request in the Send Partner Portal (a service restart is included as part of the portal request).

Risk value flags¶

Rule results can be mapped to risk value flags, which can then be used in displayCriteriaExpressions to show or hide subsequent actions:

{
  "riskValueFlagConfig": {
    "facilityRiskValidationBlock": "ERROR"
  }
}

This writes a flag to the risk record that other display expressions can check — for example, preventing an action from becoming available until a validation rule passes.

Facility risk validation¶

A key use of the rules engine is validating that a DEC risk is correctly linked to its Master contract (binder). The Facility Risk Validation group evaluates whether the risk meets all facility criteria.

Note

For facility risk validation to work correctly, the risk must be linked to its master risk. Check the masterRiskConfig block in be_config.json (S3 business config) and the binder reference fields in the submission config if validation is not evaluating correctly.

Rules database¶

The rules_engine database schema contains:

Table	Contents
`rule_group`	Named groups of rules
`rule`	Individual rules with conditions and outcomes
`scheme`	Data mapping schemes linking risk data to rule inputs
`mapping`	Field-level mappings within a scheme

Rules themselves are configured in the rules engine database — not in the client config repository. This is typically done by the rules engine team or by DevOps with input from the implementation engineer.