The same person assessed it. And approved it?

Coming soon

Check who assessed and approved each claim. See which claims broke the rule, which could not be checked and the events behind the result.

Examine the control Open the worked example

Ghost Observatory Reader showing rule findings from a synthetic claims process. — Earlier Reader capture · rule findings from the published synthetic claims sample.

01 / Internal controls

What is separation of duties?

Separation of duties is a control that divides incompatible responsibilities between people. In a claims approval process, a policy might prohibit the same person from both assessing a claim and approving it. Another organisation may have different rules, delegates or exceptions. The control must be defined before the data is checked.

In process mining, a rule compares the events and recorded identities for the same work item. A flagged claim identifies a recorded control exception; it does not establish misconduct.

Declare the rule.

Identify the incompatible steps: Assess Claim and Approve Claim in this example.

Identify the people.

Match the recorded assignee or actor for each step to the same claim.

Count what can be checked.

Keep missing steps and unidentified people outside the checked population. Show them separately.

02 / Published synthetic example

See the findings and what was checked.

The published synthetic result contains 300 claims. Its separation-of-duties rule compares assessment and approval for each claim with enough recorded evidence.

109

Flagged

109 checked claims show the same recorded person assessing and approving.

115

Different people

Assessment and approval were recorded against different people.

Not checked

A required step or person was missing. These claims remain outside the checked population.

The denominator

224 of 300 claims had enough evidence to check. The result reports both the findings and the extent of the check.

03 / Reproduce the number

Verify the result with SQL.

One query on the published rules table returns 224 checked and 109 hit. Run it in your browser, or open the sample file in any SQLite viewer.

SELECT r.checked_count, r.hit_count
FROM rules AS r
JOIN analysis_windows AS w ON w.scope_id = r.scope_id
WHERE w.analysis_window = 'all'
  AND w.analysis_domain = 'process_flow'
  AND r.rule = 'role_separation'
  AND r.activity = 'Assess Claim'
  AND r.second_activity = 'Approve Claim';

The query, its result and the source rows

04 / Precision

Define the control and its evidence.

A control check depends on declared roles, reliable identity and a complete enough event history.

01
Resolve accounts to people.
Different usernames do not guarantee different people. Resolve identity using an explicit source of authority.
02
Missing is not compliant.
Records that lack a required step or actor remain visible as uncheckable and are excluded from the checked population.
03
Exceptions are business decisions.
Define how emergency approvals and permitted delegation affect the control before applying it to the records.
04
Evidence is not intent.
A same-person finding identifies a recorded control exception. It does not, by itself, establish misconduct or financial loss.

05 / Apply it

Every approval needs an owner.

Define your approval rules, connect the recorded identities and examine where the process breaches those rules.

Prepare an event log Explore control and workload analysis

Check the denominator as well as the finding.

A rule-hit count depends on which claims could be checked and how people were identified. Use the published query to verify the example before interpreting its percentage.