Skip to content

Using AI Case Checks

Info

New in Atfinity 17.

An AI Case Check evaluates a case against a plain-language description of a potential problem and reports whether the problem is present, how severe it is and how confident the assessment is. Use one wherever a pattern is easy for a compliance officer to recognise but hard to write as a rule condition.

How a check is built

A check has:

  • Condition: a RuLa condition, like a rule's, that decides which instances it runs against.
  • Problem description: a Jinja template describing the potential problem. It is rendered against the matched instance before being sent to the AI, so {{ p.first_name }} becomes a real value such as Thorben.
  • Max severity level: the highest of the five severity levels (Very Low, Low, Medium, High, Very High) the check is allowed to report. A result assessed as more severe than this is capped at it.

A check only runs for a process once it is added on that process's Components page, on the 'AI Case Checks' tab.

The minimum confidence threshold

Every result carries a confidence, shown to the user as a percentage from 50% to 95%. The 'AI Features' tab of the configuration settings has a minimum confidence, on a scale of 1 to 10: results below it are not shown to the user at all.

In the case wizard

A check is only shown in a case if its result is a problem and its confidence is at or above the threshold. Each result shows the instances it applies to. A user can raise the minimum severity or confidence shown, and can ignore a result. An ignored result stays hidden until the case data behind it changes, which reruns the check.

Badges next to the 'AI Case Check' tab in the case menu count the current results, grouped into low (Very Low and Low), medium and high (High and Very High) severity.

Reacting to results in a rule

A check's results are available in RuLa, so a rule or a transition condition on a workflow can act on them. CASE.ai_case_problems holds the results the case currently shows, CASE.ai_case_problems_by_key groups them by check, and on a matched instance p.__ai_case_problems holds only the results whose check matched that instance.

To stop a case continuing while a check reports a problem, guard the transition on the count:

CASE.number_of_ai_case_problems = 0
and CASE.number_of_pending_ai_case_checks = 0

The second half matters. When the case data behind a check changes, the check runs again, and until the new result arrives the previous one is still what the rules see. CASE.number_of_pending_ai_case_checks is the number of checks in that state, so a condition that also requires it to be zero cannot be passed on an out-of-date result.

To block on one check:

COUNT(CASE.ai_case_problems_by_key['pep_mismatch']) = 0

To block only above a severity:

CASE.ai_case_problems.count(problem => problem['severity_rank'] >= 4) = 0

A check's own condition cannot read any of these, because a check that decides whether to run on its own results never settles. Saving such a check is refused. Take the same care with a calculated information that reads them: it writes a value into the case, which is case data, which reruns the checks that depend on it.

Printing results in a document

The same five attributes are available on CASE in a document template, so a review report can list what the checks found at the moment the document was generated:

{% for problem in CASE.ai_case_problems %}
{{ problem['title'] }} ({{ problem['severity'] }}): {{ problem['description'] }}
{% endfor %}

CASE.number_of_ai_case_problems and CASE.number_of_pending_ai_case_checks come out as text, so they can go straight into a case information box. A document reads what is stored on the case, so a check whose result has not arrived yet contributes nothing; CASE.pending_ai_case_check_keys says which ones those are.

When it is off or unavailable

Turning AI Case Check off in the configuration settings stops it from running and hides existing results, but checks can still be created and edited; the 'AI Case Checks' tab shows a banner saying the feature is off. If the tenant does not have Atfinity Intelligence at all, that tab and the 'AI Features' settings tab show an empty state asking the user to contact Atfinity instead.

Example

A check with condition p is Person, max severity Very High and this problem description:

{{ p.first_name }} {{ p.last_name }} states their occupation as {{ p.occupation }} and describes their source of
wealth as: "{{ p.source_of_wealth_description }}".
Flag if this description does not plausibly account for the wealth expected from that occupation.

flags, for example, a person listed as unemployed whose source of wealth description reads "savings from my previous job", which does not explain a six-figure account balance.