Configuring 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. For an enum or a unit value you can use translate to send the label, Pakistani rather than the stored key pak. To send what an uploaded document says, use document_text, which also covers what happens to a check whose document has not been read yet. The description is rendered in the tenant's main language, whichever language the case is worked in.
• 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.

On a step of an end-user wizard

A check can also be placed on a step of an end-user wizard, where it reports its results next to the fields they are about. The element names the check, whether an open problem stops the applicant reaching the next step, and which instance of the step it belongs to. A step over p1, p2, ...ps is all Person offers p1 and p2, the identifiers it names, and an element on p2 reports what the check found about the second person rather than about all of them. An element without an identifier is reported as a configuration inconsistency, so give each one an instance before putting the configuration live.

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.translate('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.