The most expensive version of a new rule is the one that surprises you in production. Krino shows you two ways beforehand, and neither touches anything published.

​
Testing against sample data

Answers the record-by-record question: what would this rule have done to this transaction?
1

Download the template

From the scenario’s test screen. The header row is generated from your own data model — real field names, not an invented schema.
2

Fill it with your own records

Include both transactions that turned out to be fraud and ones you are confident were clean. Testing only against bad examples leads you to build a rule that declines everything.
3

Upload it and read the results

For every row you see which rules fired, what they scored and what the outcome was.
A test run uses the draft version and nothing it produces counts as a decision. It does not reach dashboards, exports or the case queue.

​
Shadow runs

Sample data cannot answer one question: what would this draft do to next week’s traffic? That is what a shadow run is for. The draft version runs in parallel over live traffic. It influences no decision; it only measures.
1

Start the run

You pick the draft version and a duration. The duration is required — shadow evaluation means a second full pass over the rules on every decision, and an experiment nobody remembers starting keeps consuming resources.
2

Wait

The live version carries on as normal throughout. Your users see no difference.
3

Read the divergences

You end up with: how often it agreed with live, where it diverged, and in which direction.

​
The divergence table

The rows falling to Unknown matter most. They mean the draft’s trigger condition has narrowed and it now says nothing at all about traffic the live version declines. Make sure you can explain that before publishing.

​
Against your own history

A shadow run only ever sees the traffic that arrives while it is open. Judging a rule against last month’s fraud means waiting a month with one — and the sample you actually want to test against is the confirmed cases, where the right answer is already known. The Against history tab on the test screen replays records you have already ingested through the version you choose.
1

Pick the window and the sample

A date range and how many records to read. The screen says which sample it took — “the most recent 500 in the window” and “500 at random” support different conclusions.
2

Compare against a version, if you want to

Usually the live one. Both versions run over the same payloads at the same instants, so the only thing that differs between the two answers is the rules.
3

Read the result

The outcome distribution, what would change if you gave it a comparison, and which rules fired.
What makes this a backtest rather than “old records scored today” is that each record is evaluated as of the moment it arrived. Velocity rules count the history that existed before that record, not the history that exists now. Krino can do this because ingested records are superseded rather than overwritten.
Records are read as the versions that were current then rather than by liveness — including records since updated and objects since deleted. Filtering to live rows would measure the surviving population instead of the traffic.
Nothing is written: no decision, no case, no webhook. The run is also deliberately bounded — a query reading history as of a past instant cannot use the indexes built for live rows. This is a measurement, not a batch job.

​
Which, when

Sample data test

While writing the rule, for fast feedback. Takes seconds.

Against history

To judge a rule against cases you already know. Takes minutes.

Shadow run

Just before publishing, to see the volume impact. Takes days.