A reasonable question, and one worth answering directly rather than deflecting: if the goal is a Ready / Needs Review / Not Ready signal, why not build a rules engine? Rules are cheaper to run, easier to audit, and don't carry the unpredictability that comes with generative models. For a narrow band of travel-risk questions, a rules engine is the right tool, and we say so below. For the problem we actually built for, it isn't, and here is why.
What a rules engine solves well
Deterministic systems excel at exactly what their name implies: known inputs mapped to known outputs. Sanctions-list screening, visa-validity lookups, a fixed set of country-entry restrictions, these are genuinely rule-shaped problems, and we treat them as such elsewhere in the stack.
Where rules break down
Rule-based systems are built from a defined structure of anticipated scenarios. When a real case falls outside that structure, the system has no path forward beyond escalation or a default answer that may not fit. As one technical breakdown of the pattern puts it, "the system cannot proceed because it does not have instructions for the scenario" (Yodaplus). Rules also treat each input in isolation, they do not weigh how several factors compound for one specific traveller in one specific place. A traveller assessment is rarely one clean variable. It is an intersection: a specific identity, in a specific city, on a specific date, against city-level, national, and diplomatic signals that shift independently of one another. That is a combinatorial problem, not a lookup table.
Why multiple models, not one
A single model, however capable, carries its own training biases into every output. Our architecture runs the assessment as a structured debate across models from different families, then synthesises a consensus. This is not a novelty; ensemble diversity is a documented technique for reducing a model's reliance on a single spurious signal. Research on diverse ensembles has found that "ensemble diversity is sufficient for shortcut cue mitigation" without needing hand-labelled examples of the bias in advance (arXiv, Mitigating Biases with Diverse Ensembles and Diffusion Models). Cross-model disagreement is a feature we surface, not an error we suppress.
The oversight requirement this satisfies, not evades
None of this removes the human from the decision. The EU AI Act requires that high-risk systems "shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use" (Regulation (EU) 2024/1689, Article 14(1)), including the ability to interpret outputs, recognise automation bias, and override the system. A rules engine can satisfy this requirement trivially, because there is nothing to interpret beyond the rule that fired. A generative system has to be built for it deliberately. Ours logs every model call, every disagreement between agents, and the reasoning behind the final synthesis, specifically so a human reviewer can see why the system said what it said, not just that it said it.
The honest trade-off
A rules engine is simpler, cheaper, and easier to certify. It is also wrong, or silent, on exactly the cases where the stakes are highest: the ones nobody anticipated when the rules were written. We chose the harder architecture because the traveller at the edge of the rule set is the traveller the rule set was supposed to protect.
Sources
Sources: Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Article 14 (Human oversight), OJ L, 2024/1689, 12.7.2024, ELI: https://eur-lex.europa.eu/eli/reg/2024/1689/oj (primary, verified against EUR-Lex); Yodaplus, on rule-based system exception handling (single-source, industry blog); arXiv 2311.16176, ensemble diversity and bias mitigation (single-source, preprint, not yet independently replicated).