# Behavior Rules ## Overview **Behavior Rules** are the decision-making engine in EDDI's Lifecycle Pipeline. They are IF-THEN rules that evaluate conversation state and trigger actions based on conditions. This is where you define **when** to call an LLM, **when** to invoke an API, and **how** your agent responds to user inputs. ### Role in the Lifecycle In EDDI's processing pipeline, Behavior Rules sit between input parsing and action execution: ``` User Input → Parser → Behavior Rules → API/LLM Calls → Output Generation ``` Behavior Rules examine the conversation memory (including parsed input, context data, and conversation history) and decide: * Which actions to trigger * Whether to call an LLM or skip it * Whether to make external API calls * What output to generate ### Key Concepts * **Rules are IF-THEN logic**: If all conditions match, execute the specified actions * **Rules are grouped**: Multiple rules can be organized into groups for better structure * **Sequential execution**: Rules within a group execute in order until one succeeds * **First match wins**: Once a rule in a group succeeds, remaining rules in that group are skipped * **Actions trigger other lifecycle tasks**: Actions like `httpcall(weather-api)` or `send_to_llm` activate other parts of the pipeline ## Behavior Rules Structure `Behavior Rules` are very flexible in structure to cover most use cases that you will come across. `Behavior Rules` are clustered in `Groups`. `Behavior Rules` are executed sequentially within each `Group`. As soon as one `Behavior Rule` succeeds, all remaining `Behavior Rules` in this `Group` will be skipped. ## **Groups** ```javascript { "behaviorGroups": [ { "name": "GroupName", "behaviorRules": [ { "name": "RuleName", "actions": [ "action-to-be-triggered" ], "conditions": [ ] }, { "name": "DifferentRule", "actions": [ "another-action-to-be-triggered" ], "conditions": [ ] }, ] } ] } ``` ## Type of Conditions Each `Behavior Rule` has a list of `conditions`, that, depending on the `condition` , might have a list of `sub-conditions`. > **If all conditions are true, then the Behavior Rule is successful and it will trigger predefined actions**. ### List of available conditions: * [Input Matcher](#input-matcher) * [Context Matcher](#context-matcher) * [Connector](#connector) * [Negation](#negation) * [Occurrence](#occurrence) * [Dependency](#dependency) * [Action Matcher](#action-matcher) * [Dynamic Value Matcher](#dynamic-value-matcher) ### General Structure `conditions` are always children of either a `Behavior Rule` or another `condition`. It will always follows that same structure. ### Description of condition structure ### Input Matcher The `inputmatcher` is used to match **user inputs**. Not directly the real input of the user, but the meaning of it, represented by `expressions` that are **resolved** from by the `parser`. ### Description | Element | Value | Description | | ------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | type | `inputmatcher` | | | configs | `expressions` |

comma separated list of

expressions such as:

expression(value),expression2(value2),

yetAnotherExpressions(anotherValue(withASubValue))

| | | `occurrence` |

currentStep - used in case if the user said it in this conversationStep

lastStep - used in case if the user said it in the previous conversationStep

anyStep - used in case if the user said it in any step if this whole conversation

never - used in case if the user has never said that, including the current step

| If the **user** would type "hello", and the parser resolves this as expressions "`greeting(hello)`" *\[assuming it has been defined in one of the dictionaries]*, then a `condition` could look as following in order to match this user input meaning: ```javascript (...) "conditions": [ { "type": "inputmatcher", "configs": { "expressions": "greeting(*)", "occurrence": "currentStep" } } ] (...) ``` This `inputmatcher` `condition` will match any `expression` of type greeting, may that be "`greeting(hello)`", "`greeting(hi)`" or anything else. Of course, if you would want to match `greeting(hello)` explicitly, you would put "`greeting(hello)`" as value for the "`expressions`" field. ### Context Matcher The `contextmatcher` is used to match `context` data that has been handed over to **EDDI** alongside the user input. This is great to check certain `conditions` that come from another system, such as the day time or to check the existence of user data. ### Description | Element | Value | Description | | ------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | type | `contextmatcher` | | | configs | `contextKey` | The key for this context (defined when handing over context to **EDDI**) | | | `contextType` |

expressions

object

string

| | | `expressions` (if `contextType=expressions`) | A `list` of comma separated `expressions` | | |

objectKeyPath (if contextType=object)

objectValue

|

Allows match via Jsonpath, such as "profile.username" (see: )

Exp: contextKey: userInfo , contextValue: {"profile":{"username":"John"}} The value to be match with the extracted JsonPath value

| | | string | `string` matching (`equals`) | ### Examples ```javascript (...) "conditions": [ { "type": "contextmatcher", "configs": { "contextType": "expressions", "contextKey": "someContextName", "expressions": "contextDataExpression(*)" } } ] (...) (...) "conditions": [ { "type": "contextmatcher", "configs": { "contextType": "object", "contextKey": "userInfo", "objectKeyPath": "profile.username", "objectValue": "John" } } ] (...) (...) "conditions": [ { "type": "contextmatcher", "configs": { "contextType": "string", "contextKey": "daytime", "string": "night" } } ] (...) ``` ### Connector The `connector` is there to all logical `OR` conditions within rules. By default all conditions are `AND` `conditions`, but in some cases it might be suitable to connect conditions with a logical `OR`. ### Description | Element | Value | | ------- | --------------------------------- | | type | `connector` | | values | `operator` (either `AND` or `OR`) | ### **Examples** ```javascript (...) "conditions": [ { "type": "connector", "configs": { "operator": "OR" }, "conditions": [ ] } ] (...) ``` ### Negation Inverts the overall outcome of the children conditions In some cases it is more relevant if a `condition` is `false` than if it is `true`, this is where the `negation` `condition` comes into play. The logical result of all children together (`AND` connected), will be ***inverted***. ### Example: ```bash Child 1 - true Child 2 - true → Negation = false Child 1 - false Child 2 - true → Negation = true (...) "conditions": [ { "type": "negation", "conditions": [ ] } ] (...) ``` ### Occurrence Defines the occurrence/frequency of an action in a `Behavior Rule`. ```javascript (...) { "type": "occurrence", "configs": { "maxTimesOccurred": "0", "minTimesOccurred": "0", "behaviorRuleName": "Welcome" } } (...) ``` ### Dependency Check if another `Behavior Rule` has met it's condition or not in the same `conversationStep`. Sometimes you need to know if a rule has succeeded , `dependency` will take that rule that hasn't been executed yet in a sandbox environment as a `reference` for an other behavior rule. ```javascript (...) { "type": "dependency", "configs": { "reference": "" } } (...) ``` ### Action Matcher As `inputMatcher` doesn't look at expressions but it looks for actions instead, imagine a `Behavior Rule` has been triggered and you want to check if that action has been triggered before. ```javascript (...) { "type": "actionmatcher", "configs": { "actions": "show_available_products", "occurrence": "lastStep" } } (...) ``` ### Dynamic Value Matcher This will allow you to compile a condition based on any http request/properties or any sort of variables available in EDDI's context. ```javascript (...) { "type": "dynamicvaluematcher", "configs": { "valuePath": "memory.current.httpCalls.someObj.errors", "contains": "partly matching", "equals": "needs to be equals" } } (...) ``` ### Size Matcher This condition type checks the size of arrays or collections in the conversation memory. ```json (...) { "type": "sizematcher", "configs": { "valuePath": "memory.current.httpCalls.results", "min": "1", "max": "10", "equal": "-1" } } (...) ``` | Config | Type | Description | | ----------- | ------ | ---------------------------------------- | | `valuePath` | string | Path to the array/collection to check | | `min` | int | Minimum size required (-1 to skip check) | | `max` | int | Maximum size allowed (-1 to skip check) | | `equal` | int | Exact size required (-1 to skip check) | ## The Behavior Rule API Endpoints The API Endpoints below will allow you to manage the `Behavior Rule`s in your EDDI instance. The **`{id}`** is a path parameters that indicate which behavior rule you want to alter. ### API Methods | HTTP Method | API Endpoint | Request Body | Response | | ----------- | ------------------------------------------------- | --------------------- | --------------------- | | **DELETE** | `/behaviorstore/behaviorsets/{id}` | N/A | N/A | | **GET** | `/behaviorstore/behaviorsets/{id}` | N/A | **BehaviorSet model** | | **PUT** | `/behaviorstore/behaviorsets/{id}` | **BehaviorSet model** | N/A | | **GET** | `/behaviorstore/behaviorsets/descriptors` | N/A | **BehaviorSet model** | | **POST** | `/behaviorstore/behaviorsets` | **BehaviorSet model** | N/A | | **GET** | `/behaviorstore/behaviorsets/{id}/currentversion` | N/A | **BehaviorSet model** | | **POST** | `/behaviorstore/behaviorsets/{id}/currentversion` | **BehaviorSet model** | N/A | ### Example We will demonstrate here the creation of a `BehaviorSet` *Request URL* `POST http://localhost:7070/behaviorstore/behaviorsets` *Request Body* ```javascript { "behaviorGroups": [ { "name": "Smalltalk", "behaviorRules": [ { "name": "Welcome", "actions": [ "welcome" ], "conditions": [ { "type": "negation", "conditions": [ { "type": "occurrence", "configs": { "maxTimesOccurred": "1", "behaviorRuleName": "Welcome" } } ] } ] }, { "name": "Greeting", "actions": [ "greet" ], "conditions": [ { "type": "inputmatcher", "configs": { "expressions": "greeting(*)", "occurrence": "currentStep" } } ] }, { "name": "Goodbye", "actions": [ "say_goodbye", "CONVERSATION_END" ], "conditions": [ { "type": "inputmatcher", "configs": { "expressions": "goodbye(*)" } } ] }, { "name": "Thank", "actions": [ "thank" ], "conditions": [ { "type": "inputmatcher", "configs": { "expressions": "thank(*)" } } ] }, { "name": "how are you", "actions": [ "how_are_you" ], "conditions": [ { "type": "inputmatcher", "configs": { "expressions": "how_are_you" } } ] } ] } ] } ``` *Response Body* `no content` *Response Code* `201` The `Location` response header contains the URI of the newly created resource: ``` Location: eddi://ai.labs.behavior/behaviorstore/behaviorsets/{id}?version=1 ``` --- # 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.labs.ai/agent-configuration/behavior-rules.md?ask= ``` 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.