Overview

Vom is a decision platform¹ SaaS. That is, software that customers use to configure automated decisions, including consuming internal and external data and running ML models.

Customers configure their automated decisioning in Vom by creating policies. Each policy runs a separate decision process, so companies with multiple automated decisions will have multiple policies. For example, a certain bank can have different policies for personal line of credit, credit card limit, and business loans.

In order to enable A/B testing and auditability, policies are versioned. That is, a policy can have several different versions of the decision process. At any time, one of those versions is the current one, but other versions might also be running as experiments (also known as challengers).

See an example in the following figure. The person_credit_limit policy has 3 versions running: the current one taking 55% of decisions and two experiments sharing 45%.

Vom distributes decisions between current and experimental versions according to their traffic configurations². See more in the Decisions documentation.

Versions are drawn as a block diagram, with blocks such as conditional blocks to test values and direct the decision flow accordingly, and assignment blocks, which assign values to variables.

Within blocks, users write short snippets of code using Vom Formulas, a simple language inspired by Excel formulas.

The parameters for taking each decision are called input variables and are configured in the Input section of the version. They can come from the Decision API call or from the Feature Store. The Feature Store is a time series database of features into which customers can push data, or it can pull data via connectors. See more about all of these in the Data documentation.

The output of an decision is composed of an overall result (e.g. Approved, Denied, etc.) configured in end blocks, plus any intermediary variables set during the decision³. Output is both returned to the API caller and also stored in the Decision History, where decisions can be debugged, downloaded for analysis, or used for back testing.

Footnotes

1. This class of software is also known as a decision engine. ↩

2. More precisely, executions are split into 100 buckets according to the hash(entity_id) % 100 and each version gets a share of the buckets according to their traffic percentage. This ensures the same client will be exposed to the same version in repeated executions. ↩

3. Including the input variables which, being variables, are echoed in the output. ↩