Skip to main content

​
Overview

Configuration rating form-logic rules determine which forms are attached to a policy or quote. Rules are stored in the rating engine revision’s config JSON (rating_engine_revisions.config.policyFormLogicConfigs). Each rule has a shouldAdd conditional expression that is evaluated during rating against the policy, insured, coverage, and form data.

​
Key Concepts

  • ratingEngineRevisionId: The rating engine revision whose config holds the rules — must already exist.
  • revisionStrategy: Controls how the revision is updated — UpdateExistingRevision modifies the specified revision in place. CreateNewRevision is not yet implemented.
  • ruleName: Human-readable name for the rule.
  • rank: Controls the position of attached forms in the output list (lower numbers appear first). Does not control evaluation order. Duplicates are permitted. Required on create, so returned rules always carry a rank.
  • step: Optional — tag controlling which form-selection contexts the rule’s output appears in. "policies" (appears during policy form selection), "quotes" (appears during quote form selection), or an array of these values. If omitted, the rule’s output only appears during policy form selection.
  • shouldAdd: A conditional expression that evaluates to true or false. When it evaluates to true, the form is attached. See Expression Shapes below.

​
API Endpoints

​
Permissions

​
GET Query Parameters

​
GET Response Properties

Each item in items has the following shape. Filters and sorts run on raw rules; response validation runs only on the surviving rows. A rule that survives filtering but has a missing or malformed id, rank, or shouldAdd returns a 400 InvalidProperties response. In practice, rules written through this API always pass validation, so this condition indicates a data-integrity issue with legacy config rather than a caller error.

​
POST Request Properties

​
Expression Shapes

shouldAdd is a recursive structure built from three variants.

​
Branch Expression

Combines child expressions with a logical operator.
Supported operator values: AND, OR.

​
Leaf Expression

Compares the value at leftKey against rightValue using the given operator.
Supported operator values: =, !=, <, <=, >, >=, IN, NOTIN, EXISTS, NOTEXISTS, SOME. Operator-specific behavior:
  • EXISTS / NOTEXISTS — check only whether leftKey resolves to a defined, non-null value. rightValue is required structurally but ignored.
  • IN / NOTIN — rightValue is either an array (membership: the leftKey value must be an element) or a string (substring: the leftKey value must appear within rightValue).
  • SOME — rightValue is a nested expression evaluated against each element of the array at leftKey. Returns false if leftKey does not resolve to an array.
  • =, !=, <, <=, >, >= — standard JavaScript-style comparison between the resolved leftKey value and rightValue.
rightValue may be a primitive, an array, null, or — for SOME — a nested expression.

​
Inverted Leaf Expression

Checks whether a static leftValue appears in the array (or string) stored at rightKey. Only the IN operator is supported in this shape.