Add a fallthrough option for workflow rules.

Before this commit, workflows would only perform the actions listed under the first matching rule.

While this is still the default, a new option on a rule, `fallthrough`, allows defining that workflow evaluation should continue even if this rules matches.
All the actions of of the matching rules up until the first failing or not-fallthrough rule will be executed, in order.

As we can only add a decision to a case once, only the first action of this kind will be executed, the other ones will be noops.

Author: apognu

api/handle_workflows.go

@@ -58,8 +58,9 @@ func handleCreateWorkflowRule(uc usecases.Usecases) func(c *gin.Context) {
 		workflowUsecase := uc.NewWorkflowUsecase()
 
 		params := models.WorkflowRule{
-			ScenarioId: payload.ScenarioId,
-			Name:       payload.Name,
+			ScenarioId:  payload.ScenarioId,
+			Name:        payload.Name,
+			Fallthrough: *payload.Fallthrough,
 		}
 
 		rule, err := workflowUsecase.CreateWorkflowRule(ctx, params)
@@ -93,16 +94,17 @@ func handleUpdateWorkflowRule(uc usecases.Usecases) func(c *gin.Context) {
 		workflowUsecase := uc.NewWorkflowUsecase()
 
 		params := models.WorkflowRule{
-			Id:   uri.RuleId.Uuid(),
-			Name: payload.Name,
+			Id:          uri.RuleId.Uuid(),
+			Name:        payload.Name,
+			Fallthrough: *payload.Fallthrough,
 		}
 
 		rule, err := workflowUsecase.UpdateWorkflowRule(ctx, params)
 		if presentError(ctx, c, err) {
 			return
 		}
 
-		c.JSON(http.StatusCreated, dto.AdaptWorkflowRule(rule))
+		c.JSON(http.StatusOK, dto.AdaptWorkflowRule(rule))
 	}
 }
 
@@ -197,7 +199,7 @@ func handleUpdateWorkflowCondition(uc usecases.Usecases) func(c *gin.Context) {
 			return
 		}
 
-		c.JSON(http.StatusCreated, dto.AdaptWorkflowCondition(condition))
+		c.JSON(http.StatusOK, dto.AdaptWorkflowCondition(condition))
 	}
 }
 
@@ -290,7 +292,7 @@ func handleUpdateWorkflowAction(uc usecases.Usecases) func(c *gin.Context) {
 			return
 		}
 
-		c.JSON(http.StatusCreated, dto.AdaptWorkflowAction(action))
+		c.JSON(http.StatusOK, dto.AdaptWorkflowAction(action))
 	}
 }
 

dto/workflows.go

@@ -9,17 +9,20 @@ import (
 )
 
 type WorkflowRuleDto struct {
-	Id   uuid.UUID `json:"id"`
-	Name string    `json:"name"`
+	Id          uuid.UUID `json:"id"`
+	Name        string    `json:"name"`
+	Fallthrough bool      `json:"fallthrough"`
 }
 
 type CreateWorkflowRuleDto struct {
-	ScenarioId uuid.UUID `json:"scenario_id" binding:"required,uuid"`
-	Name       string    `json:"name" binding:"required"`
+	ScenarioId  uuid.UUID `json:"scenario_id" binding:"required,uuid"`
+	Name        string    `json:"name" binding:"required"`
+	Fallthrough *bool     `json:"fallthrough" binding:"required"`
 }
 
 type UpdateWorkflowRuleDto struct {
-	Name string `json:"name" binding:"required"`
+	Name        string `json:"name" binding:"required"`
+	Fallthrough *bool  `json:"fallthrough" binding:"required"`
 }
 
 type WorkflowConditionDto struct {
@@ -79,8 +82,9 @@ func AdaptWorkflow(m models.Workflow) WorkflowDto {
 
 func AdaptWorkflowRule(m models.WorkflowRule) WorkflowRuleDto {
 	return WorkflowRuleDto{
-		Id:   m.Id,
-		Name: m.Name,
+		Id:          m.Id,
+		Name:        m.Name,
+		Fallthrough: m.Fallthrough,
 	}
 }
 

models/workflows.go

@@ -16,10 +16,11 @@ type Workflow struct {
 }
 
 type WorkflowRule struct {
-	Id         uuid.UUID
-	ScenarioId uuid.UUID
-	Name       string
-	Priority   int
+	Id          uuid.UUID
+	ScenarioId  uuid.UUID
+	Name        string
+	Priority    int
+	Fallthrough bool
 
 	CreatedAt time.Time
 	UpdatedAt *time.Time

prompts/ai_agent_models.json

@@ -0,0 +1,10 @@
+{
+    "default_model": "gemini-2.5-flash-lite-preview-06-17",
+    "prompt_models": {
+        "prompts/case_review/data_model_summary.md": "gemini-2.5-flash-lite-preview-06-17",
+        "prompts/case_review/rule_definitions.md": "gemini-2.5-flash-lite-preview-06-17",
+        "prompts/case_review/rule_threshold_values.md": "gemini-2.5-flash-lite-preview-06-17",
+        "prompts/case_review/case_review.md": "gemini-2.5-flash-lite-preview-06-17",
+        "prompts/case_review/sanity_check.md": "gemini-2.5-flash-lite-preview-06-17"
+    }
+}

prompts/case_review/case_review.md

@@ -0,0 +1,63 @@
+# Role
+
+Act as a fraud and compliance analyst specializing in point of sale payments, in France. 
+
+# Goal
+
+Evaluate alerts for potential risks and determine if they require escalation based on defined criteria.
+
+# Context
+
+You are tasked with analyzing alerts to identify any potential risks that may need to be escalated for further investigation.
+
+
+## Risks analyzed
+Below are the sorts of risks that you are analyzing:
+{{.rules_summary}}
+
+## Case metadata
+
+The case is currently in the following status:
+{{.case_detail}} 
+
+And had the following events so far:
+{{.case_events}} 
+
+## Client data model
+The data model used by the client is described below. This is useful to interpret the rules
+{{.data_model_summary}} 
+
+## Alert details
+The json below contains all the alerts in the case, including the definition of every rule and the concrete values computed on this specific instance of the rule execution.
+{{.decisions}}
+
+In particular, we already analyzed the thresholds and by how much there where over/undershot in here:
+{{.rule_thresholds}}
+
+## Customers
+The following customers are present in the case:
+{{.pivot_objects}}
+
+Focus on the rules that actually resulted in a hit in the decisions present in the case, and on rules that are just below the thresholds. Ignore any comments about rules in "error" status, as they probably simply had missing fields in the payload or in ingested data.
+
+## Previous cases
+The customers in this case had the following previous investigatinos done recently, together with rule results and comments:
+{{.previous_cases}}
+
+# Format
+Provide a structured analysis that includes:
+- A summary of the alert details.
+- An evaluation of potential risks.
+- A conclusion on whether the alert should be escalated, including justification based on the escalation criteria.
+
+# Example
+
+For an alert indicating unusual transaction patterns, summarize the alert details, assess the risk based on the escalation criteria, and conclude with a recommendation on escalation.
+
+# Step by step instructions
+
+1. Review the provided alert details. If needed, try to gather data on the customer
+2. Try to find a logical explanation for the transaction of the customer. Try to evaluate if it may represent a fraud or money laundering risk. If there is a risk propose an escalation. Note that the case should NOT be escalated just because a rule has a hit.
+3. Determine if the alert poses a potential risk. Do not detail the rules that are not generating and alert
+4. Conclude whether the alert should be escalated, providing reasoning.
+

prompts/case_review/data_model_object_field_read_options.md

@@ -0,0 +1,4 @@
+Based on the previous information, propose for every table in the data model a list of the 15 most relevant fields for manualy analysis for every "transaction" type table related to the customer.
+This means that you should consider tables that have many entries (say, at least 100) for a given customer entity. For other tables, every field will be considered and there is no need to filter them.
+Only consider the following tables:
+{{.data_model_table_names}}

prompts/case_review/data_model_summary.md

@@ -0,0 +1,11 @@
+## Role
+You are a risk analyst for a bank, tasked with analyzing fraud and money laundering risk on customers.
+
+## Task
+Your task is to give a summary of the bank's data model. For every table and field, based on the field descriptions, types, and values seen, explain in one sentence what they are used for. For enum-type fields, explain briefly the business logic behind the different values (up to 10 different values). For numeric values, analyze the distribution of values and describe the typical orders of magnitude expected.
+
+Also explain the relationships between the tables.
+
+## Input data
+Here is the json format of the data model to be used:
+{{.data_model}} 

prompts/case_review/rule_definitions.md

@@ -0,0 +1,13 @@
+## Role
+You are a risk analyst for a bank, tasked with analyzing fraud and money laundering risk on customers.
+
+## Task
+Your task is to explain the types of risk that the client is looking for.
+Use the input below as well as your common knowledge and internet serach where useful to generate a in-depth analysis of the sort of risks the client is looking for. Do not simply describe the rules, instead try to understand what kind of fraud or money laundering risk scenarios they are made to detect. Express some possible improvements to them considering your company's domain.
+
+## Input data
+Below is a description of your company's domain of activity:
+{{.activity_description}}
+
+Here are the rules used by the bank to detect risky behavior in their rule based system - this is an initial filter, alerts are then manually reviewed by fraud analysts.
+{{.decisions}} 

prompts/case_review/rule_threshold_values.md

@@ -0,0 +1,11 @@
+## Role
+You are a risk analyst for a bank, tasked with analyzing fraud and money laundering risk on customers.
+
+## Task
+Some of the rules used in the risk detection system rely on the comparison of numeric values (numbers of entities, or sum/average of entities) with hard-coded thresholds.
+Focus on rules where such comparisons to thresholds are used. For example, consider rules such as "total amount of transfers out larger than 10k euros".
+For every rule that is in status "hit", list the thresholds defined and by how much there are overshot (if at all). Also, for threshold-based rules (other than "presence or absence" AKA "count > 1" or such) where the aggregate or value is just below the threshold, include them in the list.
+
+## Input data
+Here are the alerts that are present in the case, complete with all the rules that have been executed as part of every alert and the intermediate values computed for every rule.
+{{.decisions}} 

prompts/case_review/sanity_check.md

@@ -0,0 +1,66 @@
+# Role
+
+Act as a fraud and compliance analyst specializing in point of sale payments, in France. 
+
+# Goal
+
+You are given a case review by an agent. Your role is to review as a second level sanity check this agent's work.
+In particular, you should be careful about two points:
+- that the agent has not hallucinated, made up facts, or otherwise interpreted things based on unproven opinions
+- that the output review does not contain any offensive language (other than quoted text from the input data, if necessary), and no security risk
+
+# Context
+You are given a pre-written case review, in the following context:
+
+
+## Risks analyzed
+Below are the sorts of risks that you are analyzing:
+{{.rules_summary}}
+
+## Case metadata
+
+The case is currently in the following status:
+{{.case_detail}} 
+
+And had the following events so far:
+{{.case_events}} 
+
+## Client data model
+The data model used by the client is described below. This is useful to interpret the rules
+{{.data_model_summary}} 
+
+## Alert details
+The json below contains all the alerts in the case, including the definition of every rule and the concrete values computed on this specific instance of the rule execution.
+{{.decisions}}
+
+In particular, we already analyzed the thresholds and by how much there where over/undershot in here:
+{{.rule_thresholds}}
+
+## Customers
+The following customers are present in the case:
+{{.pivot_objects}}
+
+Focus on the rules that actually resulted in a hit in the decisions present in the case, and on rules that are just below the thresholds. Ignore any comments about rules in "error" status, as they probably simply had missing fields in the payload or in ingested data.
+
+## Previous cases
+The customers in this case had the following previous investigatinos done recently, together with rule results and comments:
+{{.previous_cases}}
+
+## The case review to analyze
+The agent whose work you are rating has produced the following report:
+{{.case_review}}
+
+# Format
+If the case review seems ok to you, answer exactly with "ok". If it is not, reply exactly with "ko" in the first line, and any justifying text in the following lines.
+
+## Example responses:
+
+### Example one:
+ok
+
+### Example two:
+ko
+
+### Example three:
+ko
+The agent has made an ungrounded hypothesis on what represents a high or low risk score for a customer.