Intro

These models reflect how different Sliderule concepts fit together. This is by no means an exhaustive model of all Sliderule concepts, but serves as a good high level overview of the most important ones. In addition, if you are self hosting and are trying to use the Sliderule database to generate insights, these models also represent the relational model sliderule uses to store its data. Each node, corresponds to a sliderule table similarly named.

Workflow Model

Everything in Sliderule operates around this concept of a workflow. A workflow contains all the information you need to execute logic, and is structured hierarchically as follows:

In this diagram you'll notice a couple things. First, if you've used sliderule through the UI you should recognize the right most side of the tree. A workflow has multiple rule sets and a rule set has multiple rules. Another way to put this is every rule has exactly one rule set, and every rule set has exactly one workflow.

Now, lets discuss the left side of the tree. In Sliderule, a workflow often changes over time. In addition, one of the many benefits of Sliderule is the ability to explain exactly how every past decision was made. In order to accomplish this it is necessary to keep a full change history of every workflow in Sliderule. Every time someone makes a change to a workflow (like renaming a workflow) a new workflow version is created to represent that new state. This means at any given time, you can describe the entire state of a workflow (including its rule sets and rules) simply by its workflow version. Note: this includes

Analogously, every time a rule set or rule is changed, a new rule set version and rule version is created respectively. These are useful concepts if you want to see the lifecycle of a rule or rule set over time. For example, for a given rule set, its entire change history is captured in its rule versions.

Execution Model

Every workflow in Sliderule can be executed. The artifacts and actions each execution can take can vary widely, so its important to define the key components well.

Lets discuss each of these concepts left to right, excluding the workflow which we covered in the last section.

Current Version and Deployed Version

As described in the last section, the state of a workflow at a given time can be described as a single workflow version. This allows us to define the "Current Version" as the workflow version that represents the state of a workflow at the current time. The "Deployed Version" is the workflow version that is currently being run in production. When someone hits our API and asks to execute a workflow, the "Deployed Version" is what gets executed.

Execution

Every time someone executes a workflow, an artifact is created that we call, an Execution. This artifact points to all the side effects and execution statistics associated with a given execution.

Accumulator

When an execution is run, the resulting rule set and rule executions are written to a series of accumulators. Although not shown above, an accumulator will always correspond to a rule set version, and consequently a rule set. An easy ways to count the number of times a rule set has been run, is by counting the number of accumulators associated with that rule set. The accumulator also captures individual rule execution information.

Data Source Call

In a workflow you are allowed to enrich the data you are working with by calling out to an API or a Database or a Spreadsheet. Whenever you do this, that call is represented as a Data Source Call. This object captures all the request and response information associated with that given call. You'll notice that there is a line between the Accumulator and the Data Source Call. As we mentioned above, each rule set execution corresponds to an accumulator. If that rule set was say, an API block, there would also be a relationship made to the Data Source Call created for that API call.

Alert

Each execution can create from zero to one alerts. An alert in sliderule is how you surface things that require manual review to your analysts.

Customer

A customer in Sliderule is how you group multiple executions together. Each execution can be associated with zero or one customer, and a customer can be associated with 0 to N executions.