Here’s the finding. Try to prove it wrong.

Coming soon

The sample result holds 300 synthetic claims and 7,402 events. One rule runs across all of them: whoever assesses a claim must not approve it.

Reader
Rules & checks109 broken
Result file
The rules table109 broken
Independent SQL check
A query on the events109 claims
Rule hits
One row per event218 rows
Your export
claims_ops.csvThe source row
From finding to source record

01 / Finding

One rule, every claim.

How separation-of-duties checks work

The rule is separation of duties: the person who assesses a claim must not approve it. The Engine checks it on every claim that has both steps and a person on record.

FindingSample result

109 of 224

claims were approved by the person who assessed them.

That is 49% of the claims the rule could check. The other 76 could not be checked: a step or a person is missing from the records.

Every claim in the sample, one dot each300 claims, one dot each. 109 gold dots: the person who assessed the claim also approved it. 115 teal dots: different people did the two steps. 76 open rings: not checked, because a step or a person is missing from the records.
  • 109 same person assessed and approved
  • 115 different people
  • 76 not checked: a step or a person is missing from the records

02 / Proof

A finding should survive inspection.

Each flagged claim identifies the assessment, the approval and their source rows. Follow that trail through the result file, then run an independent SQL recount. The guide takes you through all five steps.

Run the five steps on the sample

Hypothetical planning exercise

Budget the review work.

The finding gives you a count of claims to inspect. Add a review-time allowance and an hourly cost to plan the work. This hypothetical exercise combines the published sample with two planning assumptions. It is not an Observatory price, a measured customer outcome or an Engine calculation.

Review budget: published count and explicit assumptions
Input or resultValueBasis
Claims to inspect109Rule hits in the published synthetic sample
Review time per claim10 minutesPlanning assumption
Reviewer cost£40 per hourPlanning assumption, including employment costs
Planned reviewer time109 × 10 = 1,090 minutes18 hours 10 minutes of review capacity
Planned review budget(1,090 ÷ 60) × £40 = £726.67Budget derived from the count and assumptions

Use your own review-time allowance and cost rate for a real investigation. This estimates the review budget. A claim about financial losses or savings needs separate evidence.

Discuss a pilot using your exports

Download the sample

03 / Refusals

Rejected rows, explained.

Rejected rows are excluded from calculations and listed with their source file, row number and reason.

Three rejected rows in the sample.

The sample records each rejection explicitly. Here is what failed and where. Row IDs count data records, excluding the CSV header.

  • claims_ops.csvrow 2236a required field is missing
  • step_export.csvrow 321the timestamp cannot be read
  • step_export.csvrow 322the end comes before the start

In claims_ops.csv record 2236, case_id and activity are empty. In step_export.csv record 321, start_time is 2026/02/30 25:61:00.000, an invalid date and time. Record 322 has end_time 2026/03/24 07:00:00.042, before its start_time of 2026/03/24 07:06:18.501.

04 / Next

Open the Reader views.

The worked example preserves the earlier Reader preview of this result. The Reader tour shows a separate development demo. Explore the current views or see how a YAML contract maps your own exports.

Tour the Reader What it reads See the installation steps

Work with the source

Need to prepare your own event log?

Start with a precise ID, declared order and trustworthy timestamps.

Open the event log guide

Reproduce this example, then prepare your own.

The published claims result is a sample, with its own Engine version. Keep that scope when checking its SQL; use the input guide when moving to a real export.