SaolixGroup
Every Saolix product is designed around one line. Above it, AI is allowed to help. Below it, only rules decide. We call it the determinism boundary, and it matters more than any model we could put above it.
The idea is simple to say and surprisingly hard to hold. Language models are useful in compliance work: they read messy evidence quickly, explain a match in plain English and help an analyst decide where to look first. They are also probabilistic. Ask the same question twice and the answer can change. A screening decision that a bank must defend to an examiner cannot work like that.
So we split the work. This piece describes how that split is implemented in Saolix Eagle, our AML and sanctions screening engine.
Below the line: rules decide
When Eagle screens a name, the verdict comes from a deterministic pipeline. The name is normalised and transliterated, then compared against the sanctions lists through a sequence of matching methods. The scores are fused, and the fused score is mapped by configured thresholds (changed only with a second person's approval) to one of three verdicts:
- PASS: no meaningful match
- REVIEW: a possible match that a person must look at
- FAIL: a strong match, but only when an identifier such as a date of birth or document number was supplied with the screening. Without one, even a strong name match is capped at REVIEW and goes to a person.
The rules version in force is recorded with every screening, and the reasons attached to a verdict deliberately exclude anything that varies from run to run, such as timings. The same input under the same rules gives the same verdict.
The model can suggest where to look. It cannot change what the rules concluded.
Above the line: AI assists
Eagle has two kinds of AI help. In the analyst screen, a triage copilot explains each alert from the network graph and from similar resolved cases; no language model runs on that path. Separately, Raia, an optional AI agent available through Eagle's API, runs a small open language model hosted locally, inside the customer's environment. Eagle can also show an AI-written summary in the case view. Nothing is sent to an outside AI service.
Raia labels an alert as likely noise or needing review, with a confidence and a reason, to help decide where to look first. The labelling runs at temperature zero to keep it as stable as a model can be. If the model is unreachable, the label falls back to review: when in doubt, a person looks.
The guard on the line
The boundary is not a policy document. It is code. Before any AI label is used, a guard checks it against the rule engine's result. If the model says noise but the verdict is FAIL or REVIEW, or the match score is above a set level, the label is overridden to review and marked as guarded. Anything the client code does not recognise as an explicit noise label is also treated as review.
And nothing downstream uses the AI label to close a case. Eagle returns it as what the code calls a non-authoritative annotation, and nothing in the product acts on it. There is no path by which Raia or the copilot resolves an alert on its own.
The AI can always be switched off
AI assistance has its own switch, marked in configuration as not decision-affecting, because it isn't: with AI assistance off, every screening still reaches exactly the same verdict. The analyst just loses the help. And whatever the AI says is kept only as an advisory note alongside the case, never as part of the decision.
Why this is the right trade
It would be easy to let the model do more. It is often right. But "often right" is not a standard a regulator accepts, and it is not one a customer should accept either. Keeping the model above the line means it can be upgraded, replaced or switched off without changing a single decision. It means an examiner can ask why an alert fired and receive an answer that does not depend on a model's mood that day.
That is the determinism boundary. The same line is designed into K2M, F2X and Shield, and you can see it in action in the Eagle Simulator.