Translating decisions into the digital realm

David Katz, Tomas Sande, Carlos Gitto September 30, 2023

Introduction

For this article we want to introduce CXDP, a research project where we study how we can improve the development of internal business tools by focusing on the interaction between domain experts and technology teams. In the first stage of the project, we interviewed professionals working at biotech startups, large consulting firms and e-commerce companies in the US and Latin america. Our objective was to understand how human criteria can be integrated into digital tasks through a low-code digital experience.

Human bias in decision making tends to be regarded as a relevant topic, at least in the fields of behavioral psychology and cognitive science. In regular life, decisions are made based on multiple factors that we sometimes do not acknowledge consciously, be it a part of our daily routine or a reaction to an external factor (like dodging a bad driver).

When we refer to bias, we do not intend the meaning that limits it to the negative tendency a subject may have towards certain criteria or interpretation, we want to acknowledge that bias is sometimes necessarily good. Without the need to deep dive into specific works, like those proposed by Tversky and Kahnneman, we can refer to the concept of heuristics, those rules or criteria that provide a context to the subject, facilitating the interpretation of the information it receives and the realization of tasks. In plain words, they are shortcuts to enhance the solution of a problem.

Now, let's consider another concept, the idea of an expert in a certain field of knowledge. Although critical and socratic schools of thought would oppose our assertion of the ability to truly be an expert, society generally attributes to some individuals the qualification of “expert” to point out that they have exceedingly good knowledge on a certain topic.

Taking these concepts into our spectrum, we could assume that experts have some heuristics and criteria that necessarily helps or improves decision making in the fields of their domain. Authors like Nassim Taleb would disagree in at least a moderate degree by arguing that there is ample evidence of expert criteria being far from the actual carrying out of events, being it sometimes perjudicial to the possibility of anticipating or adequately solving the problems proposed in the long run.

For what we care about in this particular project, we won't take into consideration decisions that are meant to forecast events, but we will focus on those domains of knowledge in which experts facilitate the interpretation of information. For example, despite any expert negationism we could promote, we would probably agree that building a bridge with an engineer is better than doing it with an airline pilot or a lawyer (I would definitively rank the pilot second).

This is the case of genetic algorithms applied to clinical psychiatry, as they also require the intervention of a prepared experts in order to diagnose symptoms, together with the genetic profiles, into a determined condition (bipolar, depression, etc.). Another example could be AML (Anti Money Laundering) practices, where lawyers establish and fine-tune the criteria by which to judge certain operations as suspicious, or insurance brokers that analyze their pool of clients in order to minimize the portfolio's overall risk (or adjust price in accordance with it).

Considering these expert interventions, we embarked in the development of a rule making tool based both on propositional logic and programming languages like SQL (Structured query language).

Our aim was to make the prototype of a rule making system that would allow experts without software knowledge to make their criteria easily available to developers, which could be conventionally termed as a low-code platform or even no-code.

Determining Context

As our core focus, we wanted to facilitate the process by which domain experts provide developers with feedback, while also enabling them to share their knowledge in an easily available format.

At first, we focused on both the method by which rules would be implemented and the way in which they could be made accessible. Regarding implementation, we made a web application that contains buildable forms in which propositions can be created in similarity with logical rules.

To allow users to create collections of rules, they have to generate the properties for the cases in which these will be applied. For example, if we are to determine which genes and behaviors should indicate a certain condition, we must determine properties (gene phenotype, observed behaviors, etc.), determine if they are present (boolean values) and then establish which condition is to be assigned to that particular case (return values).

To facilitate our example, let's see how a collection of rules would be built:

In order to allow users to build their rules, they have to first establish a name for the collection, let's call it “genetic algorithm” or GEN-ALGO.

After naming, we have to establish which properties are going to be the ones which we will consider for our cases. To make it simple, we could use genes with their corresponding variations and symptoms or conducts we observe from the patients.

Let's remember we are not making a thorough review of clinical psychiatry, we are just exemplifying how a specific practice could be translated into a digital application.

Once we have determined the case properties, we should establish which are the return values we want for those cases that comply with our determined properties.

In our theoretical case, we now have a schema with properties in which we will judge cases that contain the established properties and, given the conditions we will set in the rules, will have determined return values.

Making Rules

After defining the environment in which our decisions will have to be made, we start by making the specific rules that will provide a determined return value according to those cases.

For our general purpose, any rules within a schema are built with the same building blocks. We create the rules by generating the logic behind how we would examine or solve a determined case. In propositional logic, we could propose that if one condition is given, or two, then we can infer a consequence.

An example of these logical statements would be:

If p then q

p → q

If p and q then r

(p ∧ q) → r

Information processing is closely related with logical thought, although it is a great hurdle to adequately transfer criteria regarding the way in which we evaluate conditions to expect certain outcomes.

Given the difficulties that arise with complex statements in propositional logic, we tried to facilitate the main propositions by implementing standard elements and conditional statements.

To understand these, we propose starting from an example which is a basic IF THEN statement. This statement will affirm that given certain conditions, a certain value will have to be returned.

p → q

The IF GROUP statement provides a cumulus of IF THEN, allowing the user to make a concatenation of conditions. All of these can then be subjected to the conditionals AND / OR, which amplifies the rule spectrum.

In this case, being that the variable is an enumerate datatype, we assign the condition IS or IS NOT (boolean) and then the type of condition within the variable we expect.

In our example, we will select The GENE A to be Type 1 and then establish the next condition, which will end in a tautology, in which we will say that it is then not type 2. This is basically saying the same thing twice.

But, we could establish another condition by which the return value is the affirmation that another gene phenotype must be of a certain type.

Let's see how a combined, more extensive statement could look like for determining a certain phenotype. In this case, we will state that if 3 conditions are given together, or one alone, then it should return PhenotypeA, returning by default PhenotypeB. This concludes that the general condition is PhenotypeB, being that certain conditions must occur for that property to change.

The amount of rules and information we can process with them depends mostly on the dataset we are applying our criteria to. If we have only two properties for ten cases, then taking the trouble of building rules may not be justified, being that we can easily count with our fingers those cases that apply to our criteria.

Now, if we wanted to evaluate ten million insurance petitions in accordance with thirty variables for each one of them, while also grouping them in certain groups, then establishing general criteria would definitely facilitate the process.

In order to make results easily accessible, and to provide a very elemental analysis to the user, we provide a results tab in order to see how the rules have been applied to the provided dataset. This can be shown as a table or as a bar chart.

Results Table

Results Bar Chart

Our aim is not to build an integrated Business Intelligence view, but to provide the rule makers with some preview on the distribution of the criteria they establish for the data they are modeling This can then be exported via API to more sophisticated and contrived BI applications.

Accessibility for Developers

Although there are other components for the users, let´s shift our focus towards those functionalities that facilitate accessibility to the core of the tool. As with any modern digital platform, we have included a rich API into CXDP that allows developers to programmatically conduct any action that could be done in the UI.

The key concept we wanted to promote with CXDP is the idea of having non-technical users managing domain specific logical rules and an API engine that can call the rules to serve technical teams. After surveying developers and analysts from different ecommerce and finance companies we realized that applying rule based logic at scale is being done in two different ways: on the fly, and batch.

On the fly requests in CXDP are HTTP requests that are made by an external system into CXDP to apply a series of decisions to a case. The API engine will apply the decisions architected by the analysts to any data that is sent to CXDP and produces a response that is consumed by the http client. An example of on the fly requests would be an automated credit system that approves loans programmatically by connecting the Web UI of an application to the set of rules created by the approvals department.

Regarding batch requests, these would be the case of rules that need to be applied to many rows of data at scale. In this scenario, we transpile our logic and case rules to SQL, for which we have created an integration with Google Big Query in order to allow petabyte scale workloads. Any rule that can be applied to a case of data on the fly can be applied to millions of rows using batch based processing.

To improve overall platform flexibility, we defined an internal representation system loosely based on JsonLogic that allows us to seamlessly compile our rules into different systems.

For batch requests, we convert our internal representation into BigQuery SQL and interface with Google Cloud to manage the application of rules at scale. When provided the project and dataset ID, we apply the SQL rule directly over the data stored in Google Cloud.

On the fly requests are processed by our http server by using a small python module that reads and applies our logic directly. Due to the decoupling and abstraction of the system we could also communicate rules back to the http clients directly and process data locally instead of applying the decision rule to the case data on the CXDP http server.

Conclusions

At its core, CXDP is both a no-code platform for creating logic rules on data schemas and, at the same time, an API that exposes those rules and schemas for developers to connect them with the required projects or applications.

The key problem CXDP solves is the excessive spending of time and effort in automating and managing knowledge within organizations and technical processes, as it accelerates and standardizes the way technical teams interact with domain experts.

CXDP promotes a centralized method where non technical teams can have full ownership of the business logic applied across different tech projects, while developers have an easy and accessible way of interfacing with critical domain specific logic.

For more information on this project, send us an email or direct message, we are always enthusiastic about sharing our conclusions and research.