All of Krino rests on six concepts. Once these are clear, the rest of the UI and the API falls into place on its own.

Scenario

A set of decisions bound to one event type. It determines which table is read, which events it runs on at all, and which queue the outcome reaches. Most organisations end up with a handful: one for card payments, one for loan applications, one for withdrawals.

Version

A scenario’s rules and thresholds at a point in time. You work on a draft; the live version is untouched. Publishing swaps them and keeps the previous one on record.
Each decision records which version produced it. Looking at a decision months later, you see the rules that ran that day — even if the rule has changed since.

Rule

A condition tree and a score. If the condition holds, the score is added to the total. Scores can be negative; discounting a trusted customer is the most direct way to cut false alarms.

Threshold

The boundary that turns a total into an outcome. There are three, in ascending order:

Pivot

The field decisions are grouped on — usually the customer number. Decisions sharing a pivot value collect into the same case. Without a pivot, one customer’s ten transactions would become ten separate investigations.

Case

The file that decisions requiring review collect into. It lands in a queue, gets assigned to an analyst, gets annotated and reaches a conclusion. If it is reported to a regulator, that lives in the same file.

Put together

1

An event enters a scenario

If it passes the trigger condition, it is evaluated.
2

The live version's rules run

Every rule that fires adds its score.
3

Thresholds decide the outcome

Approve, review, block-and-review or decline.
4

A case opens if needed

By pivot value it joins an existing file, or starts a new one.