Rules engines for eligibility: why AI explains and verified rules decide

Ask a general-purpose chatbot whether you qualify for a student visa and you will usually get a confident, well-written answer. It may even be right. The trouble is that you cannot tell which parts are right, which rule it relied on, or whether that rule was still in force last month. For a question with real consequences, fluent is not the same as correct.

That gap is why KeşifAtlası, our visa and relocation eligibility company, is built on a rules engine for eligibility. Verified rules decide the outcome. AI explains the outcome. People handle the questions neither should answer alone. This article describes how we think about that design — what a rule is, how it is stored and versioned, what AI is allowed to do around it, and what happens when an official rule changes overnight. The pattern applies well beyond visas: benefits, grants, scholarships, insurance cover, loan pre-checks and programme admissions all have the same shape.

What an eligibility rules engine actually is

At its simplest, a rules engine takes two inputs — a set of facts about a person and a set of rules — and returns an outcome with reasons.

The facts are answers: nationality, age band, purpose of stay, education level, whether the person holds an offer letter, how much they can show in funds. The rules are conditions: "applicant must hold an acceptance letter from a recognised institution", "applicant must be able to show a stated minimum of funds", "applicants of these nationalities must apply from their country of residence".

The engine evaluates each relevant condition and returns something like:

• Likely eligible — all required conditions met on the answers given.
• Not eligible on current answers — one or more hard conditions fail, with the specific reason.
• Needs review — the answers touch a condition that is ambiguous, discretionary or outside what the engine can judge.

That third outcome matters as much as the first two. A good eligibility system knows the edge of its own competence. We come back to it below.

What the engine is not: it is not a model reasoning its way to a conclusion, and it is not a set of if-statements scattered through application code. It is a deliberately separate layer, with its own data, its own review process and its own release history. This is the concrete version of a principle we apply across the group, described in AI explains, verified data decides.

Rules are data, not code

The most important design choice is to treat rules as structured data with provenance, not as logic embedded in the product.

Each rule in a well-designed eligibility database carries roughly these fields:

Two of these deserve a comment.

Confidence type separates rules that are binary from rules that are not. "Must hold a passport valid for the length of stay" is a hard requirement. "Officers may consider ties to the home country" is a discretionary factor. The engine should never turn a discretionary factor into a pass or fail. It can flag it, explain it and route it to review.

Last verified is different from effective from. A rule can be in force for years; we still want to know that someone checked it recently. A stale verification date is a signal to re-check, not a reason to stop answering — but it should be visible internally.

Storing rules this way has practical benefits. Non-engineers can review them. Changes produce a readable diff. The same rule can be shown to a user in plain language and evaluated by the engine without two copies drifting apart. And the rules database becomes an asset the company owns, independent of any model provider.

Why a language model should not decide

It is tempting to skip the rules layer and let a capable model read official guidance and answer directly. We decided against that for KeşifAtlası, for four reasons.

Reproducibility. The same person, asking the same question twice, should get the same answer. A rules engine guarantees that. A model, even at low temperature, does not — and small wording changes in the question can shift the answer.

Traceability. When someone asks "why am I not eligible?", the honest answer is a specific rule with a specific source. A model can generate a plausible reason, but that reason is not guaranteed to be the one that actually drove the output.

Currency. Official rules change. A model's training data has a cutoff, and retrieval over web pages can surface an outdated page as easily as a current one. A versioned rules database with effective dates knows which rule applies on which date.

Accountability. When a rule is wrong in our database, we can find it, fix it, and identify every assessment it affected. When a model's reasoning is wrong, there is nothing concrete to fix.

None of this means AI is useless here. It means AI has a different job.

What AI does do: explanation, intake and translation

Inside KeşifAtlası, AI works around the rules engine rather than inside it. Its jobs are the ones language models are genuinely good at.

Explaining outcomes. The engine returns structured results: rule IDs, pass or fail, the input values that mattered. The model turns that into a clear, calm explanation: what the result means, which requirement is not met, and what the person could look into next. It is given the plain-language rule statements and sources as context, and its output is checked against a schema so it cannot introduce a requirement that is not in the result. See Structured outputs and schema validation.

Helping with intake. People describe their situation messily. "I finished a two-year programme but it's not really a degree" needs to become a structured answer about education level. AI can suggest the mapping and ask a clarifying question; the person confirms. The engine only ever evaluates confirmed answers.

Translation and tone. KeşifAtlası starts from Türkiye, so many users will read results in Turkish while the official sources are in another language. The model helps produce readable explanations, while the rule statements themselves are human-reviewed.

Answering follow-up questions — within limits. A person can ask "what counts as proof of funds?" and get an answer grounded in the rule's reviewed text. If the question goes beyond what the rules database covers, the model says so rather than improvising.

The boundary is simple to state: the model may explain a decision; it may not make one. If an explanation and the engine's result ever disagree, the engine's result is the one shown, and the mismatch is logged as a defect.

Designing the questionnaire: the free test

The rules engine is only as good as its inputs. In practice, most of the product design effort goes into the questions.

A few principles we apply:

• Ask only what a rule needs. Every question must map to at least one rule condition. If no rule uses it, we do not ask it. This keeps the test short and keeps sensitive data to a minimum, which matters a great deal for a product that touches nationality, finances and family situation.
• Use bands where exact values are not needed. If a rule only cares whether funds exceed a threshold, ask the band, not the exact balance.
• Branch early. Purpose of stay and nationality determine most of the rest. Ask them first and skip everything that cannot apply.
• Allow "not sure". A person who does not know whether their qualification is recognised should not be forced to guess. "Not sure" routes that condition to review instead of producing a false fail.
• Show progress honestly. People abandon forms that feel endless. A visible, accurate step count helps.

This short questionnaire is the free test at the top of KeşifAtlası's funnel. How that connects to the paid report is covered in From free test to paid report.

Versioning: every answer knows its rule set

Here is the design detail that separates a trustworthy eligibility product from a quiz: every assessment stores the rule-set version that produced it.

When a person completes the test, we record their confirmed answers, the rule-set version, the outcome and the list of rules that fired. Six months later, if they ask why their report said what it said, we can reproduce it exactly — even if the rules have changed three times since.

This also means we can answer a harder question: which past assessments would change under the new rules? When a funding threshold goes up, we can identify reports produced under the old threshold where the person's answers sat between the old and new figures. Whether and how to notify those people is a product and consent decision — see Marketing consent vs product consent — but the ability to find them comes from versioning.

The same idea underpins how we treat prompts: explanation prompts are versioned too, and a report records which prompt version wrote its explanation. See Prompt versioning and evaluation.

When the official rules change

Rules change without warning. A ministry updates a funding requirement. A new route opens. A document requirement is added for one nationality. For an eligibility product, this is not an edge case; it is normal operations.

We treat a rule change as a release, with the same discipline as a code release.

1. Detect. Someone responsible for a jurisdiction watches its official sources. Monitoring can help flag that a page changed, but a person decides whether the rule changed.
2. Record. The reviewer writes the new version of the rule: new condition, new plain-language text, source link, effective date. The old version is closed with an end date, not deleted.
3. Review. A second person checks the new rule against the source. For a small team this may be the other founder or a trained reviewer; the point is two sets of eyes on anything that changes an outcome.
4. Test. The rule set is run against a library of saved example cases — synthetic profiles covering typical and edge situations, never real users' data. Every case whose outcome changes is inspected. An unexpected change usually means the new rule was written too broadly. See Environments and test data.
5. Release. The new rule-set version goes live with its effective date. The product shows the date rules were last updated for that route.
6. Follow up. Affected past assessments are identified. Support content and explanation context are refreshed.

A worked example

Imagine a destination country announces that, from the first of next month, the minimum funds required for a particular study route will rise.

The jurisdiction reviewer sees the announcement on the official site. They create version 4 of rule STUDY-FUNDS-01, with the new threshold, a link to the announcement, and an effective date of the first of next month. Version 3 gets an end date of the last day of this month. A second reviewer confirms the figure and the date.

The test library runs. Twelve synthetic cases change outcome, all of them profiles with funds between the old and new thresholds — exactly as expected. One additional case changes, a profile on a different route. Investigation shows the condition was accidentally attached to both routes. The reviewer fixes it, re-runs, and only the expected twelve change.

On release day, anyone taking the test for a start date after the first of next month is assessed against version 4. Anyone whose planned start date is earlier is assessed against version 3 — because effective dates are evaluated against the person's intended timeline, not today's date. Existing reports show a short note that the rule has since changed.

No model retraining. No prompt rewrite. No guesswork about which answers were affected.

Routing hard questions to people

Some questions do not belong to software at all. Discretionary decisions, unusual immigration histories, complex family situations and anything that looks like legal advice should reach a qualified person or be clearly declined.

KeşifAtlası's engine has three ways to trigger this:

• A discretionary rule fires. The outcome becomes "needs review", with an explanation of why.
• The person answers "not sure" on a condition that matters. Review rather than a guessed result.
• The follow-up conversation goes out of scope. The explanation layer detects a question it cannot ground in the rules and offers a route to a person instead of an answer.

Designing these hand-offs well — what the person sees, how quickly they hear back, what context travels with them — is its own topic. See Human escalation in AI products.

We are also explicit in the product that an eligibility result is an informational assessment, not a legal opinion or a guarantee of a visa decision. Official authorities decide applications. Our job is to help people understand where they stand and what to prepare.

Common mistakes in eligibility products

Having looked at how eligibility tools tend to go wrong, a few patterns come up repeatedly.

Hard-coding rules in the front end. It works for the first version and becomes unmaintainable the first time a rule changes. Nobody can see what the product actually believes.

Deleting old rules. If the old version is gone, past answers cannot be explained. Close rules with an end date; never overwrite them.

Treating "not eligible" as the end. A person told they fail one requirement wants to know which one and whether anything can change. A good result names the rule and, where appropriate, what the person could look into.

Mixing sources of different authority. Official regulations, embassy guidance and community forum advice are not equal. Only the first two belong in the rules database, and the source field makes the difference visible.

Letting the explanation layer add requirements. A model asked to "be helpful" will sometimes add sensible-sounding extra documents. Schema validation and a check that every requirement mentioned maps to a fired rule stop this.

Collecting more data than rules need. Every extra question is extra sensitive data to protect and extra friction. See Data retention and deletion.

How this fits the rest of the group

KeşifAtlası uses the group's shared AI gateway for its explanation layer: model routing, budgets, safety hooks, schema validation and logging. See Building an AI gateway. What it does not share is its rules database, its users or its prompts. Those belong to KeşifAtlası alone, in line with Shared infrastructure, separate data.

The same pattern — verified system decides, AI explains — shows up elsewhere in the portfolio. MerchNivo takes numbers from the Shopify store, never from a model. CastLyra takes verification status from its verification records. Eligibility is simply the case where the stakes are most personal and the rules change most often, which makes the discipline most visible.

A short checklist for building your own

If you are designing an eligibility product — visas, grants, benefits, admissions — these are the questions we would ask first:

1. Is every outcome produced by a written rule with a source, not by a model?
2. Does every rule have a stable ID, a version and effective dates?
3. Can you reproduce any past assessment exactly?
4. Is there a "needs review" outcome, and does it route somewhere real?
5. Does every question map to at least one rule?
6. Is there a saved test library that runs on every rule change?
7. Does the explanation layer have a schema that prevents it from adding requirements?
8. Does the product say plainly that the result is informational and who actually decides?

If the answer to any of these is no, that is where to start.

Summary

A rules engine for eligibility separates two jobs that are easy to blur: deciding and explaining. At KeşifAtlası, verified, versioned rules — each with a source, effective dates, an owner and a reviewer — decide whether a person looks eligible, not eligible or in need of review. AI turns that structured result into a clear explanation, helps with messy intake and translation, and declines questions it cannot ground. Every assessment records the rule-set version that produced it, so past answers can be reproduced and affected reports can be found when rules change. Rule changes are handled as releases: detected, recorded, reviewed, tested against a library of synthetic cases and released with effective dates. The result is an eligibility product that can be trusted precisely because it can show its work.

Questions and answers

What is a rules engine for eligibility?

It is a system that evaluates a person's answers against a set of written, verified rules and returns an outcome such as eligible, not eligible or needs review. Each rule has a source, an effective date and a version.

Why not let an AI model decide visa eligibility?

Language models can produce fluent answers that are confidently wrong or out of date. KeşifAtlası uses verified rules to decide the outcome and uses AI only to explain that outcome in plain language.

How does KeşifAtlası handle a rule change?

A reviewer records the change with its official source and effective date, the rule set is tested against saved example cases, and the new version is released. Past reports keep a record of the version that produced them.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Marketplaces & Consumer Products

NextPositioning consumer AI as reflection and entertainment, honestly →